[squeak-dev] Please try out | Inspector Refactoring =)

Marcel Taeumel marcel.taeumel at hpi.de
Mon May 11 12:45:25 UTC 2020


> Well if Squeak had named interfaces or protocols had names, you could use them. :-)

Did somebody already try to extend the MIME types spec to Smalltalk objects? :-)

text/plain ... String
text/richtext ... Text
text/html ... String or Text (via #asTextFromHtml)
image/* ... Form (via ImageReadWriter)

?? application/object ... Object ??

Best,
Marcel
Am 11.05.2020 14:39:41 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Marcel Taeumel <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> schrieb am Mo., 11. Mai 2020, 14:23:

> There are cases where the target actually supports multiple formats/types and lets the user choose. Like the paste as plain text vs rich text example.

I think that I have lazy (or deferred) evaluation in mind. The drag source puts a passenger into the transfer morph and adds some rules on how to convert that passenger into other objects. The drop target then chooses the kind of representation, triggering conversion transparently. Yes, MIME types can serve as a common protocol between source and target.

That sounds alright.

Hmm...on second thought ... it does not matter whether this conversion is deferred or not.

Maybe not here, but if there are many formats or complex content, eager conversion could be costly.


The inspector would store its field behind a special MIME type like "application/inspector-field" as well as "object/generic" (?) and maybe even "text/plain". The last option would free the target from having to decide whether to call #asString or #printString on "object/generic". :-)

Well if Squeak had named interfaces or protocols had names, you could use them. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200511/e82b8f08/attachment.html>


More information about the Squeak-dev mailing list