- Pharo-users - lists.pharo.org

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

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