Re: [Pharo-users] [Pharo-dev] Information on Spec development
Spec 2 was integrated in Pharo. Here is the changelog: https://github.com/pharo-project/pharo/pull/3667 We will wait a few weeks before reverting all the changes to Spec 1 in order to let people who started to develop in Spec in Pharo 8 migrate to this version. -- Cyril Ferlicot https://ferlicot.fr signature.asc Description: OpenPGP digital signature
Re: [Pharo-users] [Pharo-dev] Information on Spec development
Cyril wrote > Until now, the T is before the prefix. (For example TIceXXX for > Iceberg). So I followed what was already done. But then IMHO Iceberg is wrong too and do not correctly and consistently use their own prefix in front of classes/traits. See other samples like traits in which are also there already: Epicea -> EpTEventVisitor Fuel -> FLTGlobalClassOrTraitSerializationTest Glamour -> GLMTBlockTags Moose Algos -> MalTEdgeNode ... and where "prefix" is first as it should be. There are several reasons why "prefix" should be first: 1. As the name says: it is a prefix - so it would be obvious to have it in front of the class or trait name. 2. Prefixes are a workaround because we do not have namespaces (yet). Following the "prefix" always first rule we could later have a separation into namespaces more easily later when migrating. 3. If someone uses a prefix starting with a "T" too, like "TPL" for Template library then people get easily confused with class/trait mix of "TTPL" and "TPLT" looking like a typo or thinking all are traits because "T" is the first. Therefore - Prefix should be two (as in Seaside), ideally three letters and ideally in uppercase IMHO we should define a rule to have three uppercase letters at least for the base image. - order should be "prefix" and then class or trait name (where trait names start with "T". Smalltalk provides lots of freedom. But without rules and discipline it easily ends up in inconsistencies, chaos, a mess... Looks like even Pharo engineers miss a code guide these days ... Bye T.
Re: [Pharo-users] [Pharo-dev] Information on Spec development
On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl wrote: > > > Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in > the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter instead > of SpMorphicGenericAdapter. Iceberg needs the former, my tool the latter. > What is the strategy for that. For now I did a #asSpec2Adapter in my image > that return the SpMorphic.. class. > Hi, The extensions in Spec2 are renamed to not conflict with Spec 1. You are looking for #asSpAdapter ;) > Norbert > > -- Cyril Ferlicot https://ferlicot.fr
Re: [Pharo-users] [Pharo-dev] Information on Spec development
> On 13 Aug 2019, at 15:19, Cyril Ferlicot wrote: > > On Tue, Aug 13, 2019 at 2:59 PM Norbert Hartl wrote: >> >> >> Ah yes, I just wrote on discord. I did a tool in spec2 which I cannot use in >> the newest pharo. The #asSpecAdapter uses still MorphicGenericAdapter >> instead of SpMorphicGenericAdapter. Iceberg needs the former, my tool the >> latter. What is the strategy for that. For now I did a #asSpec2Adapter in my >> image that return the SpMorphic.. class. >> > Hi, > > The extensions in Spec2 are renamed to not conflict with Spec 1. You > are looking for #asSpAdapter ;) No, you are not :) #asSpAdapter will be removed. You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) Esteban > >> Norbert >> >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >
Re: [Pharo-users] [Pharo-dev] Information on Spec development
On Tue, Aug 13, 2019 at 3:25 PM Esteban Lorenzano wrote: > > > No, you are not :) > #asSpAdapter will be removed. > > You are looking for SpMorphPresenter (and/or the method SpPresenter>>newMorph) > In the Spec repository I deprecated #asSpAdapter with a mesage explaining SpMorphPresenter should be used. It will be integrated in next Spec integration. > Esteban > > -- Cyril Ferlicot https://ferlicot.fr
