- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Class syntax brainstorming

by Denis Kudriashov

2017-05-22 13:40 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Why can't instance variables/slots not be Symbols as well ... To me current slot syntax is good enough. Anybody have objections?

May 22, 2017

Re: [Pharo-dev] Class syntax brainstorming

by Denis Kudriashov

2017-05-22 13:53 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Class <<< #MyClass > superclass: #Object; > uses: #MyTrait; > vars: { #a. #b }; > classVars: { #A. #B }; > package: #MyPackage; > tags: #(Core); > layout: #MethodDictionaryLayout. And few notes: all messages should be optional. It is not necessary to specify Object superclass. By default class can belongs to Unpackaged package. I think superclass should be defined as symbol because it can not exists.

May 22, 2017

Re: [Pharo-dev] Class syntax brainstorming

by Thierry Goubier

The build / partial object syntaxes are interesting in the way they could be integrated with RB in creating RB actions (RDAddClassChange / RBAddClassVariableChange / RBAddInstanceVariableChange) that could then be played on "build". Gives you a nice undo/redo capability and Epicea integration to boot. Also, it could be valuable to not completely build / install the class in some cases, and manipulate the abstract structure without compiling it. Regards, Thierry 2017-05-22 13:53 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > My idea was to ask concrete metaobject for new object definition: > > Class <<< #MyClass > superclass: #Object; > uses: #MyTrait; > vars: { #a. #b }; > classVars: { #A. #B }; > package: #MyPackage; > tags: #(Core); > layout: #MethodDictionaryLayout. > > for class side: > > Metaclass <<< #MyClass > vars: { }. > > Or: > > Class classSide <<< #MyClass > > for trait: > > Trait <<< #MyTrait > uses: #AnotherTrait; > package: #MyPackage; > tags: #(Core Traits) > > for trait class side: > > ClassTrait <<< #MyTrait > uses: #AnotherClassSideTrait > > > 2017-05-22 9:25 GMT+02:00 Luc Fabresse <luc.fabresse(a)gmail.com>: > >> "basic mechanics, only THIS one in the image!" >> ClassDefinition new >> superclass: Object; "optional. If not specified, Object by default ;-)" >> name: #A; "optional and create an anonymous class if not specified" >> instVars: 'a b c'; >> traits: {TEquality}; >> package: 'Plop'; >> createClass. " this message sent might be hidden by the browser when >> accepting" >> > > I would not call it #createClass but something like #install. Because > #createClass can be also interesting message to get new class without > affecting live system. > And #install should be default version of #installInto: anEnvironment. > >

May 22, 2017

Re: [Pharo-dev] Class syntax brainstorming

by Denis Kudriashov

Hi. My idea was to ask concrete metaobject for new object definition: Class <<< #MyClass superclass: #Object; uses: #MyTrait; vars: { #a. #b }; classVars: { #A. #B }; package: #MyPackage; tags: #(Core); layout: #MethodDictionaryLayout. for class side: Metaclass <<< #MyClass vars: { }. Or: Class classSide <<< #MyClass for trait: Trait <<< #MyTrait uses: #AnotherTrait; package: #MyPackage; tags: #(Core Traits) for trait class side: ClassTrait <<< #MyTrait uses: #AnotherClassSideTrait 2017-05-22 9:25 GMT+02:00 Luc Fabresse <luc.fabresse(a)gmail.com>: > "basic mechanics, only THIS one in the image!" > ClassDefinition new > superclass: Object; "optional. If not specified, Object by default ;-)" > name: #A; "optional and create an anonymous class if not specified" > instVars: 'a b c'; > traits: {TEquality}; > package: 'Plop'; > createClass. " this message sent might be hidden by the browser when > accepting" > I would not call it #createClass but something like #install. Because #createClass can be also interesting message to get new class without affecting live system. And #install should be default version of #installInto: anEnvironment.

May 22, 2017

Re: [Pharo-dev] Class syntax brainstorming

by Guillermo Polito

I'd also put in the pot a more declarative, less-smalltalkish-syntax approach: Class { name: 'A', superclass: Object, a: InstVar, b: InstVar, c: InstVar } Of course this could evolve. Some people will say that this is too verbose if you have lots of instance variables. I'd say that having too many instance variables is a code smell :) Guille On Mon, May 22, 2017 at 1:27 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > If we can get rid off the myriad of class creation methods count me in. :) > > I would do something like: > > ClassBuilder new > name: #A; > superclass: Object; > addInstanceVariableNamed: 'a'; > addInstanceVariableNamed: 'c'; > addBooleanSlotNamed: 'z'; > addClassVariableNamed: 'D'; > use: SomeTrait; > use: SomeOtherTrait; > beWeak "if you want a weak subclass"; > build > > With all of this optional. If we can avoid to pass nil as superclass for > the cases you don't have a superclass that would be good, maybe an specific > method in the builder ? > > On Mon, May 22, 2017 at 4:25 AM, Luc Fabresse <luc.fabresse(a)gmail.com> > wrote: > >> Hi, >> >> Following Pharo Days, I brainstormed about some possible class definition >> syntaxes. >> What I have in mind: >> >> "basic mechanics, only THIS one in the image!" >> ClassDefinition new >> superclass: Object; "optional. If not specified, Object by default ;-)" >> name: #A; "optional and create an anonymous class if not specified" >> instVars: 'a b c'; >> traits: {TEquality}; >> package: 'Plop'; >> createClass. " this message sent might be hidden by the browser when >> accepting" >> >> "---------------" >> "Some IDEAS (but I did not find one that I really like) of >> scripting/shorter syntaxes that must ALWAYS end up calling the above basic >> mechanics at the end:" >> >> Class fromDefinition: [ :def | >> def name: #sub; >> instVars: 'w r g'; >> superclass: Object ]. >> >> Object subclass "<-- returns a subclass of Object but the problem is >> that the new class is muted each time and the class definition is not >> explicit" >> name: #A; >> ivs: 'a b c'; >> traits: { TEquality }. >> >> { #superclass -> Object. >> #name -> #sub. >> #instVars -> 'a b c' } asClass. >> >> { Object asSuperclass. >> #sub asClassName. >> 'a b c' asInstVars. >> 'c' asClassVar } asClass. >> >> "litteral approach" >> #( name A >> superclass Object >> instVars #(a b c) >> instVar d >> ) asClass >> >> >> #Luc >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

May 22, 2017

Re: [Pharo-dev] Class syntax brainstorming

by Sven Van Caekenberghe

Why can't instance variables/slots not be Symbols as well ... > On 22 May 2017, at 13:27, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > If we can get rid off the myriad of class creation methods count me in. :) > > I would do something like: > > ClassBuilder new > name: #A; > superclass: Object; > addInstanceVariableNamed: 'a'; > addInstanceVariableNamed: 'c'; > addBooleanSlotNamed: 'z'; > addClassVariableNamed: 'D'; > use: SomeTrait; > use: SomeOtherTrait; > beWeak "if you want a weak subclass"; > build > > With all of this optional. If we can avoid to pass nil as superclass for the cases you don't have a superclass that would be good, maybe an specific method in the builder ? > > On Mon, May 22, 2017 at 4:25 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi, > > Following Pharo Days, I brainstormed about some possible class definition syntaxes. > What I have in mind: > > "basic mechanics, only THIS one in the image!" > ClassDefinition new > superclass: Object; "optional. If not specified, Object by default ;-)" > name: #A; "optional and create an anonymous class if not specified" > instVars: 'a b c'; > traits: {TEquality}; > package: 'Plop'; > createClass. " this message sent might be hidden by the browser when accepting" > > "---------------" > "Some IDEAS (but I did not find one that I really like) of scripting/shorter syntaxes that must ALWAYS end up calling the above basic mechanics at the end:" > > Class fromDefinition: [ :def | > def name: #sub; > instVars: 'w r g'; > superclass: Object ]. > > Object subclass "<-- returns a subclass of Object but the problem is that the new class is muted each time and the class definition is not explicit" > name: #A; > ivs: 'a b c'; > traits: { TEquality }. > > { #superclass -> Object. > #name -> #sub. > #instVars -> 'a b c' } asClass. > > { Object asSuperclass. > #sub asClassName. > 'a b c' asInstVars. > 'c' asClassVar } asClass. > > "litteral approach" > #( name A > superclass Object > instVars #(a b c) > instVar d > ) asClass > > > #Luc >

May 22, 2017

Re: [Pharo-dev] Class syntax brainstorming

by Gabriel Cotelli

If we can get rid off the myriad of class creation methods count me in. :) I would do something like: ClassBuilder new name: #A; superclass: Object; addInstanceVariableNamed: 'a'; addInstanceVariableNamed: 'c'; addBooleanSlotNamed: 'z'; addClassVariableNamed: 'D'; use: SomeTrait; use: SomeOtherTrait; beWeak "if you want a weak subclass"; build With all of this optional. If we can avoid to pass nil as superclass for the cases you don't have a superclass that would be good, maybe an specific method in the builder ? On Mon, May 22, 2017 at 4:25 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi, > > Following Pharo Days, I brainstormed about some possible class definition > syntaxes. > What I have in mind: > > "basic mechanics, only THIS one in the image!" > ClassDefinition new > superclass: Object; "optional. If not specified, Object by default ;-)" > name: #A; "optional and create an anonymous class if not specified" > instVars: 'a b c'; > traits: {TEquality}; > package: 'Plop'; > createClass. " this message sent might be hidden by the browser when > accepting" > > "---------------" > "Some IDEAS (but I did not find one that I really like) of > scripting/shorter syntaxes that must ALWAYS end up calling the above basic > mechanics at the end:" > > Class fromDefinition: [ :def | > def name: #sub; > instVars: 'w r g'; > superclass: Object ]. > > Object subclass "<-- returns a subclass of Object but the problem is that > the new class is muted each time and the class definition is not explicit" > name: #A; > ivs: 'a b c'; > traits: { TEquality }. > > { #superclass -> Object. > #name -> #sub. > #instVars -> 'a b c' } asClass. > > { Object asSuperclass. > #sub asClassName. > 'a b c' asInstVars. > 'c' asClassVar } asClass. > > "litteral approach" > #( name A > superclass Object > instVars #(a b c) > instVar d > ) asClass > > > #Luc >

May 22, 2017

Re: [Pharo-dev] Iceberg help

by Esteban Lorenzano

> On 22 May 2017, at 10:26, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi Stephane, > > Your url looks wrong. > It should be: git@github.com:pharo-graphics/Bloc.git or git@github.com:ducasse/Bloc.git yes, they are like this :) > >> Le 21 mai 2017 Ã 11:29, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> a Ã©crit : >> >> So I tried to use iceberg to contribute to bloc >> >> I entered git(a)github.com <mailto:git@github.com>:ducasse/pharo-graphics/Bloc.git >> >> and >> >> git(a)github.com <mailto:git@github.com>:ducasse/pharo-graphics/Bloc >> >> and iceberg tells me that there is a parse error?????? >> >> Then I tried >> >

May 22, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60495 Home: https://github.com/pharo-project/pharo-core

May 22, 2017

[pharo-project/pharo-core] 9c3b4e: 60495

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9c3b4e263319754e8dff9d15b1ce7d9c91f09ab4 https://github.com/pharo-project/pharo-core/commit/9c3b4e263319754e8dff9d15… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-05-22 (Mon, 22 May 2017) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60494.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60495.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60494.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60495.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Sources.package/SourceFileArray.class/instance/private/createReadOnlyFiles.st Log Message: ----------- 60495 20064 ClassTest>>#testMethodsReferencingClass uses non-existing BehaviorTests https://pharo.fogbugz.com/f/cases/20064 20074 Red-pane-of-death when sources file missing https://pharo.fogbugz.com/f/cases/20074 http://files.pharo.org/image/60/60495.zip

May 22, 2017