2017-08-21 15:39 GMT-03:00 Peter Uhnák :
> I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:` is
> often used as a constructor initialization pattern (as per Kent Beck's
> Smalltalk book).
I use setX: with the same purpose, as per the same book recommendation.
But isn't #na
I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:`
is often used as a constructor initialization pattern (as per Kent Beck's
Smalltalk book).
Using `className:` could be confusing, as it could be unclear whether you
are changing the name of the class itself, or the name of t
I avoid get/set prefixes in method selectors, however it is a "good
practice pattern" the use of the "set" prefix as a private accessor.
I use it to build initialized instances,
MyClass class>>#attribute: anObject
^self new setAttribute: aString
In some cases MyClass doesn't have the `#attribu
its inconsistent to start using (set) in front of the name of methods and
unnecessary
className:
makes more sense to me
Another way to do this instead have something like classMetaData which can
be a dictionary containing all the data like name of the class, method
dictionary etc this way we ens
> On 20 Aug 2017, at 23:48, Brad wrote:
>
> I vote for setClassName:
>
setName: is better because this is what is there since many many years… and by
just using it
we must need to deprecate one method, not two.
Marcus
I vote for setClassName:
Brad Selfridge
> On Aug 20, 2017, at 5:30 AM, Stephane Ducasse wrote:
>
> Thanks for all the information. In Pharo 70 Object does not understand
> name so it will already be a step in the right direction.
>
> I think that we should do two things.
> - Address simply th
Thanks for all the information. In Pharo 70 Object does not understand
name so it will already be a step in the right direction.
I think that we should do two things.
- Address simply this problem for example using setName: or
setClassName: instead of name:
- start to prototype for a future a solu
On 17 August 2017 at 21:52, Stephane Ducasse
wrote:
> We should not accept such kind of behavior.
> name: should not change the name of the class.
>
I had exactly such a problem a couple of weeks ago :).
I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in MyClass
class>>on:
The irony is that there is no such bug in Squeak.
Class does not require such selector.
But it "inherits" it in Pharo because of Trait implementation (via TClass).
Why Trait itself requires #name: is another question...
IMO it does not.
If I replace the two local send in Trait by direct i.var. acc
Stephane Ducasse-3 wrote
> any idea is welcome
From
http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-td4859734.html
:
Issue 16947: Class-side Inst Var "#name" Allowed, But Breaks System
https://pharo.fogbugz.com/f/cases/16947/Class-side-Inst-Var-name-Allowed-But-Breaks-Sy
I have the impression that we should rethink the meta interface of
classes and reflective calls.
On Fri, Aug 18, 2017 at 10:44 AM, Denis Kudriashov wrote:
> Hi
>
> I wrote proposal in issue
>
> 2017-08-18 0:52 GMT+02:00 Tim Mackinnon :
>>
>> Is this a goal we can all share for 7.0?
>>
>> Sort out
Hi
I wrote proposal in issue
2017-08-18 0:52 GMT+02:00 Tim Mackinnon :
> Is this a goal we can all share for 7.0?
>
> Sort out the expert tools (like git etc), but equally enable that
> simplicity you expect for a child/newbie/expert...
>
> I'm in!
>
> Tim
>
> Sent from my iPhone
>
> > On 17 Aug
Is this a goal we can all share for 7.0?
Sort out the expert tools (like git etc), but equally enable that simplicity
you expect for a child/newbie/expert...
I'm in!
Tim
Sent from my iPhone
> On 17 Aug 2017, at 20:52, Stephane Ducasse wrote:
>
> Hi guys
>
> my son coded in Pharo 60
>
> te
On Thu, Aug 17, 2017 at 05:23:28PM -0300, Esteban A. Maringolo wrote:
> What are the odds?
100%, this _always_ happens to some student. (You just need to omit a single
semicolon and you've just broke it.)
What are the odds?
The ability to break a system in a few steps seems to be an inherited trait.
My daughter (2 years old) was randomly punching my keyboard and caused
a segfault that I couldn't reproduce afterwards.
Regards!
Esteban A. Maringolo
2017-08-17 16:52 GMT-03:00 Stephane Ducasse :
On jeu. 17 août 2017 at 21:53, Stephane Ducasse
wrote:
> Hi guys
>
> my son coded in Pharo 60
>
> testGuessUrlPart
>
> |dg8|
> dg8 := GameItem new;
> name: 'Dragon Quest VIII : Journey Of The Cursed King';
> console: 'PS2'.
>self assert: dg8
16 matches
Mail list logo
