checking the name of the class should be enough, if you want to be more safe you could also check method names too.
On Mon, Aug 17, 2015 at 12:16 PM Franck Warlouzet < [email protected]> wrote: > It could be easily done, but in a ugly way to me. The only thing you know > about a configuration package is that its name begins with > 'ConfigurationOf', or it has some specific methods. There is no data above > a package to know if it is a regular one or a configuration. Am I wrong ? > If there is, it can be done in a better way. > > Franck > > ------------------------------ > From: [email protected] > Date: Mon, 17 Aug 2015 09:04:09 +0000 > To: [email protected] > Subject: Re: [Pharo-dev] Projects are slowly getting to live... and > > > impressive you guys are busy non stop, I am feel so glad Pharo move > forward so fast. > > No I did not mean to remove configurations but rather hide them, or group > them together so they dont display together with other packages. > > On Mon, Aug 17, 2015 at 12:01 AM stepharo <[email protected]> wrote: > > First it could be worse :) We cannot build a full ecosystem without > capturing dependencies. > > Second we are (christophe) working since a year on the Cargo Package > Manager. > [Christophe knows many package manager (Java ruby and others).] > With Cargo every single package expresses its dependencies instead of > using external packages such as a Configuration. > So we will see how it goes. > > Stef > > > One of the things that annoy me is how many Configurations and Baselines > pollute the package space that are of little interest to the user. It would > be nice to group them and filter them out of Nautilus unless user asks for > them. > > I really like this new approach great work. > > On Sun, Aug 16, 2015 at 7:34 PM stepharo <[email protected]> wrote: > > > > Le 16/8/15 17:00, Sean P. DeNigris a écrit : > > stepharo wrote > >> you get a project (group) with all your packages together ready to work > ;) > > Cool! I feel more and more that the standard "Package" pane is only > useful > > for... packaging, and when one takes off the dependency management hat > and > > puts the user hat on (i.e. most of the time), what you really want there > is > > a logical view of the system. So I see three use cases: > > - Logical view of the system - I guess this was the original intention of > > Categories, but has been hijacked by Monticello > > - By project - which, as you just showed, we have now, yay! > > - By package - the least useful, but primary (up til now), view > > Indeed. > We will see what we get at the end but may be something like > > MyProject > AnotherProject > System > LowLevel > > And people will not be overwhelmed by hundreds of nice packages. :) > > I think that touching package contents under the assumption that the > package list is too long in the UI > is the wrong way to look at the problem. > Packages are unit of deployment and we need Projects - unit of > knowledge. And the UI should shows both > depending on the view we want to get. > > Stef > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Projects-are-slowly-getting-to-live-and-tp4843277p4843286.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > > > >
