March 2016 - Pharo-users - lists.pharo.org

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

by 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. Pros are that there is no endless lists of methods at class side, and by using the accessor with lazy init there is no risk for the class instance variable to be nil because of class initialization weirdness. (Not that there is a bug with it, but I am not happy with my understanding of when this happens.) > On Mar 23, 2016, at 13:41, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > as this probably doesn't have one solution I am interested in your approach, if you have any. > > The problem is that often you want to create instances (or just return constants) in some particular domain, e.g. > > 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. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

March 23, 2016

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

by Esteban A. Maringolo

2016-03-23 14:40 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> 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 make collision with your own methods a very common issue. The most common is the #name selector, which is on its way out fortunately. Esteban A. Maringolo

March 23, 2016

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

by Peter UhnÃ¡k

> > Why / how ? > As explained in the first example. Try adding #organization or #package methods to the class-side.

March 23, 2016

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

by Damien Pollet

On 23 March 2016 at 17:49, Peter UhnÃ¡k <i.uhnak(a)gmail.com> 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 ?

March 23, 2016

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

by 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 <i.uhnak(a)gmail.com> wrote: > Hi, > > as this probably doesn't have one solution I am interested in your > approach, if you have any. > > The problem is that often you want to create instances (or just return > constants) in some particular domain, e.g. > > 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. > > *1) capitalize* > > doesn't follow method naming conventions > > Color Red. > ParticipantType Organization (uncapitalized returns ClassOrganization) > VisibilityKind Package (package returns package) > > *2) have it on instance-side* > > need for an extra singleton and more typing > > Color default red. > ParticipantType default organization. > VisibilityKind default package. > > maybe #enum could work better? > > Color enum red. > VisibilityKind enum package. > > *3) use ALLCAPS* > > looks like C/Javaâ¦ ugly af > also same issue as 1) > > Color RED. > ParticipantType ORGANIZATION. > VisibilityKind PACKAGE. > > *4) use some prefix/suffix?* > > may not be enough, can be confusing when implementing a domain with given > specifications > > Color redColor. > ParticipantType organizationType. > VisibilityKind packageKind > > *5) something better?* > > All the above work (obviously) but all are broken to some extentâ¦ so it's > picking the best of the worst. -_- > > Any ideas appreciated, > > Peter >

March 23, 2016

patterns for representing enumerations/constants

by Peter UhnÃ¡k

Hi, as this probably doesn't have one solution I am interested in your approach, if you have any. The problem is that often you want to create instances (or just return constants) in some particular domain, e.g. 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. *1) capitalize* doesn't follow method naming conventions Color Red. ParticipantType Organization (uncapitalized returns ClassOrganization) VisibilityKind Package (package returns package) *2) have it on instance-side* need for an extra singleton and more typing Color default red. ParticipantType default organization. VisibilityKind default package. maybe #enum could work better? Color enum red. VisibilityKind enum package. *3) use ALLCAPS* looks like C/Javaâ¦ ugly af also same issue as 1) Color RED. ParticipantType ORGANIZATION. VisibilityKind PACKAGE. *4) use some prefix/suffix?* may not be enough, can be confusing when implementing a domain with given specifications Color redColor. ParticipantType organizationType. VisibilityKind packageKind *5) something better?* All the above work (obviously) but all are broken to some extentâ¦ so it's picking the best of the worst. -_- Any ideas appreciated, Peter

March 23, 2016

Re: [Pharo-users] ZnUrl>>#= - Why Require Same Classes?

by Sven Van Caekenberghe

> On 23 Mar 2016, at 15:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > = anObject > ^ self class == anObject class > ... > > Most of the time, I've seen a test for #species, not class. This matters > because I have a custom ZnUrl subclass that I'd like to be equal to a ZnUrl > pointing to the same place. Yes, that might be better. > While we're on the subject, I'm not an expert on hashing, but isn't it a > problem that ZnUrl>>#hash refers to #segment, which is not immutable? I don't think the mutability is a problem (collection's hash is similar), but apart from that, the hash implementation looks a bit weird (too simple). I am curious though why you subclasses ZnUrl. If you did not add structure but only behaviour you could have added some extension methods. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ZnUrl-Why-Require-Same-Classes-tp4886102.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

March 23, 2016

ZnUrl>>#= - Why Require Same Classes?

by Sean P. DeNigris

= anObject ^ self class == anObject class ... Most of the time, I've seen a test for #species, not class. This matters because I have a custom ZnUrl subclass that I'd like to be equal to a ZnUrl pointing to the same place. While we're on the subject, I'm not an expert on hashing, but isn't it a problem that ZnUrl>>#hash refers to #segment, which is not immutable? ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Why-Require-Same-Classes-tp4886102.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 23, 2016

Re: [Pharo-users] Setup a Launcher distribution for Pharo trainings/presentations on Windows

by Ben Coman

On Wed, Mar 23, 2016 at 5:22 PM, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > the kids were more interested in IoT I'm think of getting some ESP8286 [1] modules to connect Pharo (and thus possibly Phratch0 to via TCP/IP. There is a lot of buzz around IoT and I think the ESP8286 might be a way for Pharo to piggyback that. http://hackaday.com/2014/08/26/new-chip-alert-the-esp8266-wifi-module-its-5/ cheers -ben

March 23, 2016

Setup a Launcher distribution for Pharo trainings/presentations on Windows

by Torsten Bergmann

Hi Martin, >the kids were more interested in IoT and android workshops than learning smalltalk. Yes - I played lately with some stuff myself like IBeacons (which you could get now for small money already) and BLE on Android. The Smart Mirror is also a nice idea. All cool stuff as well. >i need to work on a more capturing introduction for next time. >or maybe look into smalltalk for robots or something like that. Maybe the Pi would be interesting too next time: https://www.youtube.com/watch?v=sfxFqQIuawg https://medium.com/concerning-pharo/pharo-pi-9eef257b6a21 Bye T.

March 23, 2016