Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Johan Fabry
Exactly the solution that I thought of :-) > On Mar 23, 2016, at 16:51, Esteban A. Maringolo wrote: > > 2016-03-23 16:31 GMT-03:00 Peter Uhnák : >>> I would do something like: >>> >>> Color named: #red. >>> Color named: #blue. >> >> >> That idea crossed my mind (it would be good for serializ

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Damien Pollet
On 23 March 2016 at 18:40, Peter Uhnák wrote: > Why / how ? >> > > As explained in the first example. > > Try adding #organization or #package methods to the class-side. > I'd rather have selector namespaces to remove homonymy conflicts…

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Michal Balda
If there are not so many options and if they do not programatically change, I would suggest creating a dedicated subclass for all of them: – BormParticipantOrganizationType – BormParticipantSystemType – BormParticipantPersonType All subclasses of BormParticipantType. And then use something lik

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Esteban A. Maringolo
2016-03-23 16:31 GMT-03:00 Peter Uhnák : >> I would do something like: >> >> Color named: #red. >> Color named: #blue. > > > That idea crossed my mind (it would be good for serialization from some > external data), but how would you as user/programmer know what to put in > there? > The idea of enum

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Peter Uhnák
> > I would do something like: > > Color named: #red. > Color named: #blue. > > That idea crossed my mind (it would be good for serialization from some external data), but how would you as user/programmer know what to put in there? The idea of enums is that you have a predetermined set of predeterm

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread stepharo
+1 Le 23/3/16 18:53, Johan Fabry a écrit : I would do something like: Color named: #red. Color named: #blue. et cetera. the implementation of named: is a dictionary lookup. Color class>>named: aSymbol ^self colors at: aSymbol And the colors dictionary is a class instance variable that is l

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Johan Fabry
I would do something like: Color named: #red. Color named: #blue. et cetera. the implementation of named: is a dictionary lookup. Color class>>named: aSymbol ^self colors at: aSymbol And the colors dictionary is a class instance variable that is lazily initialized by its accessor. Pr

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Esteban A. Maringolo
2016-03-23 14:40 GMT-03:00 Peter Uhnák : >> Why / how ? > > > As explained in the first example. > > Try adding #organization or #package methods to the class-side. The "only 5 reserved keywords" is just a half-truth. :) Some selectors are used by the the tooling, and with names to broad that mak

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Peter Uhnák
> > Why / how ? > As explained in the first example. Try adding #organization or #package methods to the class-side.

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Damien Pollet
On 23 March 2016 at 17:49, Peter Uhnák wrote: > > Color red. >> Color blue. >> >> Unfortunately this doesn't scale, because putting unary methods on the >> class-side is a good way to break your image. >> > Why / how ?

Re: [Pharo-users] patterns for representing enumerations/constants

2016-03-23 Thread Peter Uhnák
Plus this may typically interact with some serialization/materialization which would use the base format ('red', 'organization', 'kind'), so if there's any change to the name another mapping format would be required. On Wed, Mar 23, 2016 at 5:41 PM, Peter Uhnák wrote: > Hi, > > as this probably