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

Re: [Pharo-users] Beta testers for the Pharo mooc

by Jeff Gray

I tried the link. I got a form to send a mail but it errored with 'Missing domain' Are you getting responses? -- View this message in context: http://forum.world.st/Beta-testers-for-the-Pharo-mooc-tp4886075p4886225.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 24, 2016

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

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > I am curious though why you subclasses ZnUrl. If you did not add structure > but only behaviour you could have added some extension methods. I implemented a ProtectedUrl, which carries around the additional information it needs (in this case an authenticated client) to be accessed. ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Why-Require-Same-Classes-tp4886102p4886221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 24, 2016

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

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > I don't think the mutability is a problem I thought it was a no-no for an object's hash to ever change, which it would if the path changed, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZnUrl-Why-Require-Same-Classes-tp4886102p4886220.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 24, 2016

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

by Johan Fabry

Exactly the solution that I thought of :-) > On Mar 23, 2016, at 16:51, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2016-03-23 16:31 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> 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 predetermined >> values, so this >> >>> Pros are that there is no endless lists of methods at class side >> >> >> is actually a con, because the user doesn't know them. >> >> Everyone knows red and blue, but nobody remembers to the letter >> domain-specific props (in fact half of the class-side colors you wouldn't >> guess you could use named). >> >> BormParticipantRole class selectors "#(#Approves #Undefined #Performs >> #Initiates #IsResponsible #Acquires #Cooperates #IsInformed #Consults)" >> BormParticipantType class selectors "#(#Organization #System #Person)" >> >> But maybe Color was wrong example because the set can be very large >> (although the set of options is also limited if you consider some >> standards). > > > You can have something at the class side that return the colors name, > using this example, by returning the keys of such dictionary. > > Something like > > YourClass class>>#colors > > ^Colors ifNil: [Colors := Dictionary new at: #red put: ...; at: > #blue put: ..; yourself] > > Then you can have > > YourClass class>>#colorsConstants > ^self colors keys asSortedCollection > > Regards > > Esteban A. Maringolo > > ---> 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 Damien Pollet

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

March 23, 2016

Re: [Pharo-users] Customizing SmalltalkEditor context menu issue

by Ala'a Mohammad

Thanks for the great explanation! I had reached an almost the target menu by modify all of SmalltalkEditor, TClassDescription and AbstractNautilusUI classes methods. To be honest I'm newbie and this pragma thing seems foreign between the other pleasant experiences with smalltaking, and kind of hindrance for the exploratory nature of normal smalltalk code browsing. Regards, Ala'a On Wed, Mar 23, 2016 at 2:05 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-03-22 22:27 GMT+01:00 Ala'a Mohammad <amalawi(a)gmail.com>: >> >> Hi, >> >> I'm trying to modify the context menu of the code editor through >> modification to SmalltalkEditor class >> smalltalkEditorMenuOn: > > > Hi Ala'a > >> >> >> testing the modification with >> (PragmaMenuBuilder pragmaKeyword: 'smalltalkEditorMenu' model: nil) >> menu popUpInWorld > > > The context menu for Nautilus code pane works a bit different. > Can you test if your modifications are working in Workspace (or the > workspace are in a basic > inspector). > >> >> >> succeeds, and shows the final shape of the menu that I want (photo >> attached), but the actual one used by the system is messed up! (photo >> attached) >> >> I tried also to execute TextEditor class >> initialize, but that did not >> help. >> >> Another thing I did was trying to find senders and references to the >> SmalltalkEditor class >> smalltalkEditorMenuOn, and find none! (So who >> is calling that with a 'aBuilder'?), and the only implementation of it >> is the one I'm trying to update (more confusion - pardon the puzzled >> newbie). > > > The smalltalkEditorMenuOn: method, containing the smalltalkEditorMenu-Pragma > is not > called explicit. Instead, there is a Method SmalltalkEditor class >> > smalltalkEditorMenuKeyword > that returns the pragma name ('smalltalkEditorMenu') used to collect all > methods using this pragma > for defining the menus. > > For Nautilus, there is another step involved. First it calls > SmalltalkEditor yellowButtonMenu > this will ask for the pragma (SmalltalkEditor class >> > smalltalkEditorMenuKeyword) and builds a menu > from every method using this pragma (here only the method SmalltalkEditor > class >> smalltalkEditorMenuOn: ). > NOW it modifies this menu and adds (from all methods using the pragma > <nautilusGlobalSourceCodeMenu> and reorganize some more entries (this is > ugly, yes). > >> >> >> Attached are the photos for the original menu, target menu and the >> messed up menu. >> >> I'm using Pharo 4.0 from the official download for Linux from Pharo.org. >> >> my system is the following: >> Linuxmint 17.1 Rebecca >> 3.13.0-37-generic #64-Ubuntu SMP >> >> What I'm doing wrong? and/or what I'm missing? >> >> Thanks in advance for the help. >> >> Regards, >> >> Ala'a > >

March 23, 2016

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

by 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 like: 1) BormParticipantOrganizationType new 2) BormParticipantOrganizationType instance 3) â¦or your preferred way of making singletons The advantages? â It shows well in the autocompletion. â The values can have different behavior. â And probably some more. The disadvantages? â Serialization into a simple String (and subsequent deserialization) does not come for free, though it is easy to create methods for that. â Longer class names. â With a lot of different enums, the class count will grow significantly. Michal On 23.3.2016 20:31, Peter UhnÃ¡k wrote: > BormParticipantRole class selectors "#(#Approves #Undefined #Performs > #Initiates #IsResponsible #Acquires #Cooperates #IsInformed #Consults)" > BormParticipantType class selectors "#(#Organization #System #Person)" > > But maybe Color was wrong example because the set can be very large > (although the set of options is also limited if you consider some > standards).

March 23, 2016

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

by Esteban A. Maringolo

2016-03-23 16:31 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> 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 predetermined > values, so this > >> Pros are that there is no endless lists of methods at class side > > > is actually a con, because the user doesn't know them. > > Everyone knows red and blue, but nobody remembers to the letter > domain-specific props (in fact half of the class-side colors you wouldn't > guess you could use named). > > BormParticipantRole class selectors "#(#Approves #Undefined #Performs > #Initiates #IsResponsible #Acquires #Cooperates #IsInformed #Consults)" > BormParticipantType class selectors "#(#Organization #System #Person)" > > But maybe Color was wrong example because the set can be very large > (although the set of options is also limited if you consider some > standards). You can have something at the class side that return the colors name, using this example, by returning the keys of such dictionary. Something like YourClass class>>#colors ^Colors ifNil: [Colors := Dictionary new at: #red put: ...; at: #blue put: ..; yourself] Then you can have YourClass class>>#colorsConstants ^self colors keys asSortedCollection Regards Esteban A. Maringolo

March 23, 2016

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

by 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 predetermined values, so this Pros are that there is no endless lists of methods at class side > > is actually a con, because the user doesn't know them. Everyone knows red and blue, but nobody remembers to the letter domain-specific props (in fact half of the class-side colors you wouldn't guess you could use named). BormParticipantRole class selectors "#(#Approves #Undefined #Performs #Initiates #IsResponsible #Acquires #Cooperates #IsInformed #Consults)" BormParticipantType class selectors "#(#Organization #System #Person)" But maybe Color was wrong example because the set can be very large (although the set of options is also limited if you consider some standards).

March 23, 2016

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

by 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 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 >> <mailto:i.uhnak@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 <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile >

March 23, 2016