Smalltalk › Pharo › Pharo Smalltalk Developers

About setProperty:toValue: vs. valueOfProperty:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

stepharo

About setProperty:toValue: vs. valueOfProperty:

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:,
valueOfProperty:ifAbsentPut:,

and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?

PS: I hope (but I cannot read the code of Bloc because it crashes my vm
at startup) that Bloc and Brick will not use such patterns.

There are plague and lead to shitty and crappy code.

Stef

Henrik Nergaard-2

Re: About setProperty:toValue: vs. valueOfProperty:

| dct arr |

dct := IdentityDictionary new.

arr := #(
#valueOfProperty:
#valueOfProperty:ifAbsent:
#valueOfProperty:ifAbsentPut:
#setProperty:toValue:
#hasProperty:
).

Morph withAllSubclasses do: [ :class |
class methods do: [ :each |
each ast allChildren
select: [ :c | c isMessage and: [ arr includes: c selector ] ]
thenDo: [ :c |
dct
at: c selector
ifPresent: [ :col | col add: c ]
ifAbsentPut: [ OrderedCollection with: c ]
]
]
].

dct

------------------

Best regards,
Henrik

-----Original Message-----
From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
Sent: Thursday, November 3, 2016 8:48 PM
To: Pharo Development List <[hidden email]>
Subject: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:, valueOfProperty:ifAbsentPut:,

and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?

PS: I hope (but I cannot read the code of Bloc because it crashes my vm at startup) that Bloc and Brick will not use such patterns.

There are plague and lead to shitty and crappy code.

Stef

philippeback

Re: About setProperty:toValue: vs. valueOfProperty:

In reply to this post by stepharo

Ha, I was busy with these yesterday.

Worse bit is not the morphExtension or otherProperties stuffed into them, but rather the fact that when one puts a value into #paneColor for example, themes are not respecting that.

The morphExtension rationale is to have lightweight and heavyweight morphs.

It is not easy to balance what should be put into a method or kept into those extra places.

Now try to make a SystemWindow use the selected window color in the little downarrow menu.

You'll get into the morphs creating the sides and having a transparent fillstyle, and override the paneColor thing.

I am glad to have the dark theme. I am sad to not be able to set colors on my system windows easily (Yeah, I like the Play-Doh UI).

Maybe subclassing those Morphs making up SystemWindows would be a good idea so that we can start having a theming for the windows borders and title.

I want put the TilingWindowManager icons in the SystemWindow title bar. So, I need something more focused than just an aligment morph etc.

So we will be able to plugin a couple interesting features in it.

Phil

On Thu, Nov 3, 2016 at 8:47 PM, stepharo <[hidden email]> wrote:

I would like to be able to compare the **arguments** passed to

setProperty:toValue:

and

the ones of valueOfProperty:, valueOfProperty:ifAbsent:, valueOfProperty:ifAbsentPut:,

and

hasProperty:

I quite sure that we will discover more deadcode in morphic.

Any ideas?

PS: I hope (but I cannot read the code of Bloc because it crashes my vm at startup) that Bloc and Brick will not use such patterns.

There are plague and lead to shitty and crappy code.

Stef

stepharo

Re: About setProperty:toValue: vs. valueOfProperty:

In reply to this post by Henrik Nergaard-2

Thanks henrik this is cool and now I can do diffs and other.

I started to get the list of sender of setProperty:toValue: and one by
one analyse them.

Le 3/11/16 à 21:25, Henrik Nergaard a écrit :

> | dct arr |
>
> dct := IdentityDictionary new.
>
> arr := #(
> #valueOfProperty:
> #valueOfProperty:ifAbsent:
> #valueOfProperty:ifAbsentPut:
> #setProperty:toValue:
> #hasProperty:
> ).
>
> Morph withAllSubclasses do: [ :class |
> class methods do: [ :each |
> each ast allChildren
> select: [ :c | c isMessage and: [ arr includes: c selector ] ]
> thenDo: [ :c |
> dct
> at: c selector
> ifPresent: [ :col | col add: c ]
> ifAbsentPut: [ OrderedCollection with: c ]
> ]
> ]
> ].
>
> dct
>
> ------------------
>
> Best regards,
> Henrik
>
> -----Original Message-----
> From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
> Sent: Thursday, November 3, 2016 8:48 PM
> To: Pharo Development List <[hidden email]>
> Subject: [Pharo-dev] About setProperty:toValue: vs. valueOfProperty:
>
> I would like to be able to compare the **arguments** passed to
>
> setProperty:toValue:
>
> and
>
> the ones of valueOfProperty:, valueOfProperty:ifAbsent:, valueOfProperty:ifAbsentPut:,
>
> and
>
> hasProperty:
>
> I quite sure that we will discover more deadcode in morphic.
>
> Any ideas?
>
>
>
> PS: I hope (but I cannot read the code of Bloc because it crashes my vm at startup) that Bloc and Brick will not use such patterns.
>
> There are plague and lead to shitty and crappy code.
>
>
> Stef
>
>