[Seaside] Gemstone / Magritte

Martial Boniou Martial.Boniou at ifrance.com
Tue Aug 14 16:14:00 UTC 2007


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.

Cheers,

--
Martial

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
| 



More information about the Seaside mailing list