- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Class syntax brainstorming

by Ben Coman

On Mon, May 22, 2017 at 3:25 PM, 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 > (btw, I assume you mean mutated.) > each time and the class definition is not explicit" > name: #A; > ivs: 'a b c'; > traits: { TEquality }. > What about... Object subclass: [ :def | def name: 'MyClass' ; "optional and create an anonymous class if not specified" instanceVariables: 'a b c' ; classVariables: 'M N O'; classInstanceVariables: 'x y z' ; traits: {TEquality} ; package: 'Plop']. Object>>subclass: builderBlock ^ (builderBlock value: ClassDefinition new) createClass or similar to Guille's declarative proposal... Object subclass: { name: 'Myclass', a: InstVar, b: InstVar, c: InstVar } cheers -ben

May 22, 2017

Re: Class syntax brainstorming

by Milan Vavra

>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 like to suggest to consider replacing instVars: 'a b c'; with instVars: #( b a c ); That is, to replace the String with names separated by whitespace, by an array of Symbols, one name per line. This would make it possible to put comments right next to variable names like this: instVars: #( b "comment about b" a "comment about a" c "comment about c" ); Which is similar to what can be done in other object oriented languages like Java or C++. This would also make for nice diffs of changes to the class definition - when put into git - when instance variables are added, removed or renamed. instVars: #( b - a + d c ); Best Regards, Milan Vavra -- View this message in context: http://forum.world.st/Class-syntax-brainstorming-tp4947801p4947858.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 22, 2017

Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource

by Sven Van Caekenberghe

> On 15 Mar 2017, at 23:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 15 Mar 2017, at 20:52, Rein, Patrick <Patrick.Rein(a)hpi.de> wrote: >> >> Unfortunately, as I am trying to fix a Travis build, I can not change the call to Zinc. >> >> To be clear about this: I also think that squeaksource should serve UTF-8. >> However, at the same time a missing charset in a HTTP response means that the content >> should be decoded as ISO-8859-1 [1]. So in general this does seem to me like an issue in Zinc. >> >> I see that this might be a problem to change though, so I will consider moving the project at one point (or removing that damn umlaut :) ). >> >> Bests >> Patrick >> >> [1] https://tools.ietf.org/html/rfc2616#section-3.7.1 > > Hmm, OK, I never saw that paragraph, interesting. > Thanks for the pointer, I will put it on my todo list to think about. I recently added #defaultEncoder: as API to ZnClient and ZnServer to make it easier to change the default (Zn) character encoder used (instead of using the DynamicVariable, which can still be done, and is used behind the scenes). ZnClient new defaultEncoder: #iso88951; get: 'http://stfx.eu/small.html'. >> ________________________________________ >> From: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> on behalf of Ben Coman <btc(a)openinworld.com> >> Sent: Wednesday, March 15, 2017 19:16 >> To: Pharo Development List >> Subject: Re: [Pharo-dev] ZnInvalidUTF8 on response from squeaksource >> >> On Thu, Mar 16, 2017 at 1:25 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> This is a recurring issue. >> >> >> It would be cool if some magic(TM) could raise a dialog with an >> explanation and pull-down list to select an encoding - but maybe that >> is too much hand holding. >> >> >>> >>> The problem is that the server serves a resource, in this case text/html, without specifying its encoding. >> >> I just bumped into [1] while browsing around to learn more, but I >> don't know fully how to interpret it. >> What do you make of it saying "An XHTML5 document is served as XML and >> has XML syntax. XML parsers do not recognise the encoding declarations >> in meta elements. They only recognise the XML declaration. Here is an >> example: >> <?xml version="1.0" encoding="utf-8"?> >> <!DOCTYPE html .... >> >> compared to the page having... >> <?xml version="1.0" encoding="iso-8859-1"?> >> >> cheers -ben >> >> [1] https://www.w3.org/International/questions/qa-html-encoding-declarations >> >> >>> >>> Today, when no encoding is specified, we default to UTF-8. In this case the server silently serves a resource which is ISO-8895-1 encoded. >>> >>> The error is triggered by accessing the following URL: >>> >>> ZnClient new get: 'http://squeaksource.com/ical/?C=M;O%3DD'; yourself. >>> >>> If you inspect the response object inside the http client, you will see that the content-type is text/html. So Zn parses the incoming text using UTF-8 which fails (Zn encoders are strict by default). >>> >>> Here is how to change the default during a call: >>> >>> ZnDefaultCharacterEncoder >>> value: ZnCharacterEncoder iso88591 >>> during: [ ZnClient new get: 'http://squeaksource.com/ical/?C=M;O%3DD'; yourself ]. >>> >>> The solution would be that the server adds the proper charset specification. >>> >>> Consider the default in Pharo: >>> >>> ZnMimeType textHtml => text/html;charset=utf-8 >>> >>> The server should serve this resource using the following Content-Type: >>> >>> text/html;charset=iso-8859-1 >>> >>> This is the server's responsibility. The page in question is the MC index page, which would normally be dynamically generated. Somewhere the server decides on the encoding. That encoding does not have to change, but it should be properly indicated in the HTTP response headers. >>> >>> HTH, >>> >>> Sven >>> >>>> On 15 Mar 2017, at 17:42, David T. Lewis <lewis(a)mail.msen.com> wrote: >>>> >>>> squeaksource.com is still running on a quite old image, and I know that it >>>> has problems with multibyte characters. If you are seeing problems related >>>> to this, it's not the fault of Zinc. >>>> >>>> If you can confirm that this is what is happening, then I guess it is time >>>> to update that trusty old squeaksource.com image :-) >>>> >>>> Dave >>>> >>>>> On Wed, Mar 15, 2017 at 8:19 PM, Patrick R. <patrick.rein(a)hpi.de> wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I have been working on bringing http://squeaksource.com/ical/ up to >>>>>> speed >>>>>> for Squeak and wanted to make sure that it also works for Pharo. >>>>> Therefore, >>>>>> I have created a travis build job for Squeak and Pharo >>>>>> (https://travis-ci.org/codeZeilen/ical-smalltalk/jobs/211298950) which >>>>> pulls >>>>>> the source from squeaksource.com. >>>>>> >>>>>> Now the issue is that loading the package in Pharo fails with a >>>>>> GoferException wrapping a ZnInvalidUTF8 Exception. We figured that this >>>>>> might be the result of the squeaksource page delivering the page as >>>>>> iso-8859-1 as it contains special characters. Any ideas on how to get >>>>>> this >>>>>> to work? I do not have access to the ical repository description and I >>>>> would >>>>>> like to avoid mirroring the whole repository on GitHub. >>>>> >>>>> >>>>> In a fresh 60437 image, in Playground evaluating... >>>>> >>>>> Metacello new >>>>> configuration: 'ICal'; >>>>> repository: 'github://codeZeilen/ical-smalltalk:master/repository'; >>>>> onConflict: [:ex | ex allow]; >>>>> load. >>>>> ==> Could not resolve: ICal-Core [ICal-Core-PaulDeBruicker.5] in >>>>> /home/ben/.local/share/Pharo/images/60437-01/pharo-local/package-cache >>>>> http://squeaksource.com/ical ERROR: 'GoferRepositoryError: Could not >>>>> access >>>>> http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for >>>>> utf-8 encoding' >>>>> >>>>> >>>>> In a new fresh 60437 Image (i.e. empty package-cache) >>>>> World menu > Monticello > +Repository > squeaksource.com... >>>>> MCSqueaksourceRepository >>>>> location: 'http://squeaksource.com/ical' >>>>> user: '' >>>>> password: '' >>>>> ==> open repository then errors "MCRepositoryError: Could not access >>>>> http://squeaksource.com/ical: ZnInvalidUTF8: Illegal continuation byte for >>>>> utf-8 encoding" >>>>> >>>>> >>>>> In Chrome, opening http://www.squeaksource.com/ical >>>>> then clicking <Versions> >>>>> and the browser's View Page Source, >>>>> I see... >>>>> <?xml version="1.0" encoding="iso-8859-1"?> >>>>> >>>>> Googling: zinc iso-8859-1 >>>>> finds... >>>>> http://forum.world.st/Problem-using-Zinc-in-Pharo-4-Moose-5-1-td4825329.html >>>>> but "ZnByteEncoder iso88591" >>>>> errors with "KeyNotFound: key 'iso88591' not found in Dictionary" >>>>> and inspecting "ZnByteEncoder byteTextConverters keys sorted" >>>>> confirms this key is missing (@Sven, I'm curious why was this removed? ) >>>>> >>>>> >>>>> Now https://en.wikipedia.org/wiki/ISO/IEC_8859-1 >>>>> indicates IBM819 is an alias >>>>> and " ZnByteEncoder newForEncoding: 'ibm819' " >>>>> works okay >>>>> >>>>> So in MCHttpRepository>>#loadAllFileNames >>>>> changing... >>>>> queryAt: 'C' put: 'M;O=D' ; >>>>> get. >>>>> to... >>>>> queryAt: 'C' put: 'M;O=D' . >>>>> ZnDefaultCharacterEncoder >>>>> value: (ZnByteEncoder newForEncoding: 'ibm819') >>>>> during: [client get]. >>>>> >>>>> Then from Monticello opening the previously defined >>>>> http://squeaksource.com/ical >>>>> works!! >>>>> >>>>> >>>>> Now I was hoping that reverting #loadAllFileNames >>>>> and in Playground doing... >>>>> converters := ZnByteEncoder byteTextConverters. >>>>> converters at: 'iso-8859-1' put: (converters at: 'ibm819'). >>>>> might alleviate the problem, but no luck. >>>>> >>>>> >>>>> Anyone know a better way to deal with this that hardcoding the encoding >>>>> into #loadAllFileNames? >>>>> >>>>> cheers -ben

May 22, 2017

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