[Seaside] Gemstone / Magritte

Dale Henrichs dale.henrichs at gemstone.com
Tue Aug 14 16:42:23 UTC 2007

Just so that it is clear. For GemStone, we have removed the dependency 
for Class>>description. There is no need to change Magritte to make it 
easier to port to GemStone...This third party has disambiquated:)


Martial Boniou wrote:

>When I started to learn Smalltalk/squeak (after being an OpenStep
>programmer), I mistakenly thought that the messages' categories do this
>job. Maybe the idea of Todd, something like descriptionForMagritte
>(there's also DescriptionForPartsBin in my Object) is not too bad IMHO.
>Actually if the use #descriptions is possible as replacement, the use of 
>names like #descriptionSomething, descriptionDefintion,
>descriptionSelector are still coherent: a letter changed for less pain. 
>Globally I understand Lukas, it's very sad to loose time to change
>things like that because of third party ambiguities.
>stephane ducasse a écrit :
>| I was wondering if selector namespace would be of an help there.
>| And if the complexity (tools support...and others) introduced would  
>| be worth. I have the impression (may be bad and that goes again
>| my language designer "role/job" that idiom-driven solution like  
>| prefix are better to a certain
>| point and that this is not clear when they are really bringing a  
>| benefit).
>| Stef
>| On 7 août 07, at 22:55, Lukas Renggli wrote:
>| >>Well, this issue has certainly made me think carefully about  
>| >>introducing
>| >>extension methods and how they're named, for sure.  But I have been
>| >>mentioning it for about 2 years.  Not that it bothers me too much, I
>| >>maintain my local port with #descriptor and happily use  
>| >>#description all
>| >>over my domain classes for a description string.
>| >
>| >Exactly, after all it is no big deal. The name of this method is not
>| >particularly important to Magritte, you can answer your descriptions
>| >from whatever method you like ...
>| >
>| >>>Magritte did not start as a
>| >>>framework, but evolved from a couple of helper classes in
>| >>>SmallWiki. It is clear that any selector name potentially
>| >>>leads to conflicts. I agree that #descriptor would have been
>| >>>a slightly better, but the fact that I know a couple of
>| >>>packages that implement #descriptor is not really motivating
>| >>>me to make that change.
>| >>
>| >>Understandable, have you considered whether there'd actually be  
>| >>collisions
>| >>with those other packages in actual use?  Glorp and OmniBrowser  
>| >>use it, but
>| >>not in a way that'd collide with Magritte, what other packages do  
>| >>you know
>| >>of?
>| >
>| >Personally I've never used #description for anything else, I only
>| >observed later on that other people do. I remember considering
>| >#asDescription, but according to Kent Beck I rejected this conversion
>| >selector because (1) source and destination don't share the same
>| >protocol and (2) there is not only one correct answer.
>| >
>| >Magritte initially started in VisualWorks. There the IO accessors, the
>| >StORE source code management and some parts of the wrapper GUI
>| >framework use #descriptor.
>| >
>| >>You're right, but they don't always use English idioms.  You're a  
>| >>good
>| >>example, I've tripped over a selector or two of yours before like
>| >>beEphemeral, perfectly valid, but it doesn't feel idiomatic to me,  
>| >>I'd
>| >>expect the average American to say something like beTransient as  
>| >>an opposite
>| >>to bePersistent.  Not a big deal, just an observation.
>| >
>| >I got the idea from VisualWorks. They have a class called  
>| >#Ephemeron there ;-)
>| >
>| >>And please, don't take any of this as bitching, I'm not, you're  
>| >>one of my
>| >>favorite programmers.  Much of my current style comes from things  
>| >>I've
>| >>learned reading Seaside and Magritte sources.
>| >
>| >No problem, I understand your position.
>| >
>| >Lukas
>| >
>| >-- 
>| >Lukas Renggli
>| >http://www.lukas-renggli.ch
>| >_______________________________________________
>| >Seaside mailing list
>| >Seaside at lists.squeakfoundation.org
>| >http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>| >
>| _______________________________________________
>| Seaside mailing list
>| Seaside at lists.squeakfoundation.org
>| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>Seaside mailing list
>Seaside at lists.squeakfoundation.org

More information about the Seaside mailing list