Why do we separate class/instance methods in the browser?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Why do we separate class/instance methods in the browser?

Tim Mackinnon
Hi - this week I was asked to run a mob programming session with Smalltalk - and show a group of experienced developers Smalltalk so that they could practice mobbing around a new idea.

It worked really well, a 20 min talk explaining a bit of the ethos and a few key features and some quick syntax and they were able to charge ahead and really enjoy themselves.

It was interesting however to see what things confused them the most (and also what things impressed them - there were many).

The one that stuck out for me (and is actually mentioned in another thread this week) was the class/instance method difference. They conceptually understood the difference coming from other languages but our UI is tricky to understand with the Class button toggle we have, and if you get methods on the wrong side, like with a test, it's quite confusing.

Anyway - this got me thinking - why do we bother having a toggle in our UI for this these days? Of course we know there is a class and a metaclass but given that we have icons for methods now (and also have a
Protocol pane ) why don't we just show all the methods we have in one list and let you filter them or even see them all? It seems much easier and way more efficient to rapidly code this way.

The only question then would be how to create methods of the right type - whether to have a button to create the right template (and put the  browser code pane in the right context) or whether to indicate it by convention of the method name when creating it like + new: aSize etc. (Or even: class new: aSize etc).

The more I think about it, the more it seems like something we should consider trying both for making ourselves more efficient (I'll bet everyone has written a method on the wrong side by mistake) and also helping newcomers.

I'll bet it's quite easy to do in Calypso as well if I've understood Denis' model story properly.

Has this been tried before? Is it heretical?

Tim

Sent from my iPhone

Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Esteban A. Maringolo
2017-07-22 10:21 GMT-03:00 Tim Mackinnon <[hidden email]>:
> Anyway - this got me thinking - why do we bother having a toggle in our UI for this these days? Of course we know there is a class and a metaclass but given that we have icons for methods now (and also have a
> Protocol pane ) why don't we just show all the methods we have in one list and let you filter them or even see them all? It seems much easier and way more efficient to rapidly code this way.

> Has this been tried before? Is it heretical?

IMO it is heretical, you taught the ethos, but that instance/class is
part of the praxis (and logos) of Smalltalk.

There is no such thing as "class side", that's a good metaphor we tell
ourselves because it is useful.
Also I think that comparing it with "static" methods, as in Java, is
another resource we use but isn't directly comparable, since you can't
inherit static methods.

IMO we have "class" and "meta" definitions, that are our current
"instance" and "class side" definitions.

However I think there is still room for improvement in terms of UI,
there could be separate tabs instead of radio buttons, but there is
some screen state that you could lose if implemented improperly.

Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

K K Subbu
In reply to this post by Tim Mackinnon
On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote:

> The one that stuck out for me (and is actually mentioned in another
> thread this week) was the class/instance method difference. They
> conceptually understood the difference coming from other languages
> but our UI is tricky to understand with the Class button toggle we
> have, and if you get methods on the wrong side, like with a test,
> it's quite confusing.

It is an easy mistake to make and I have often seen this confusion in
beginners. With the attention on the methods panel and text input, it is
easy to overlook the class toggle button :-(.

An easy fix is to switch background color to differentiate between class
and instance methods in both code and input panels. A better way would
be to use tabs (like in Inspector).

BTW, I use the metaphor of toys (objects), moulds (classes) and mould
factory (metaclass). A mould is an object from the perspective of the
mould maker. Therefore operations on classes are 'methods' from the
maker's perspective (note the recursion!).

> Anyway - this got me thinking - why do we bother having a toggle in
> our UI for this these days? Of course we know there is a class and a
> metaclass but given that we have icons for methods now (and also have
> a Protocol pane ) why don't we just show all the methods we have in
> one list and let you filter them or even see them all? It seems much
> easier and way more efficient to rapidly code this way.

This perspective comes from the traditional way - code and compile. In
Pharo, we code one method at a time and sources are held in an external
file and a pointer stored in each method, so displaying all methods in
one panel would result in multiple file reads.

> The only question then would be how to create methods of the right
> type - whether to have a button to create the right template (and put
> the  browser code pane in the right context) or whether to indicate
> it by convention of the method name when creating it like + new:
> aSize etc. (Or even: class new: aSize etc).
>
> The more I think about it, the more it seems like something we should
> consider trying both for making ourselves more efficient (I'll bet
> everyone has written a method on the wrong side by mistake) and also
> helping newcomers.

Such mistakes are part of the learning curve and decrease with time.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Stephane Ducasse-3
Hi subbu

I used the same metaphor :)

Stef


On Sat, Jul 22, 2017 at 4:37 PM, K K Subbu <[hidden email]> wrote:

> On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote:
>
>> The one that stuck out for me (and is actually mentioned in another
>> thread this week) was the class/instance method difference. They
>> conceptually understood the difference coming from other languages
>> but our UI is tricky to understand with the Class button toggle we
>> have, and if you get methods on the wrong side, like with a test,
>> it's quite confusing.
>
>
> It is an easy mistake to make and I have often seen this confusion in
> beginners. With the attention on the methods panel and text input, it is
> easy to overlook the class toggle button :-(.
>
> An easy fix is to switch background color to differentiate between class and
> instance methods in both code and input panels. A better way would be to use
> tabs (like in Inspector).
>
> BTW, I use the metaphor of toys (objects), moulds (classes) and mould
> factory (metaclass). A mould is an object from the perspective of the mould
> maker. Therefore operations on classes are 'methods' from the maker's
> perspective (note the recursion!).
>
>> Anyway - this got me thinking - why do we bother having a toggle in
>> our UI for this these days? Of course we know there is a class and a
>> metaclass but given that we have icons for methods now (and also have
>> a Protocol pane ) why don't we just show all the methods we have in
>> one list and let you filter them or even see them all? It seems much
>> easier and way more efficient to rapidly code this way.
>
>
> This perspective comes from the traditional way - code and compile. In
> Pharo, we code one method at a time and sources are held in an external file
> and a pointer stored in each method, so displaying all methods in one panel
> would result in multiple file reads.
>
>> The only question then would be how to create methods of the right
>> type - whether to have a button to create the right template (and put
>> the  browser code pane in the right context) or whether to indicate
>> it by convention of the method name when creating it like + new:
>> aSize etc. (Or even: class new: aSize etc).
>>
>> The more I think about it, the more it seems like something we should
>> consider trying both for making ourselves more efficient (I'll bet
>> everyone has written a method on the wrong side by mistake) and also
>> helping newcomers.
>
>
> Such mistakes are part of the learning curve and decrease with time.
>
> Regards .. Subbu
>

Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Tim Mackinnon
I think my thread is misunderstood - I’m not saying change how methods work, class methods are fine, instance methods are fine - I’m just saying I don’t think its ideal anymore to see them so separately in our UI. It was really driven home watching great programmers struggle (sure Smalltalk is a bit different - and there are many elegant things we have, but class methods are pretty normal in many languages) - and I have a similar frustration in that I find it a straight jacket that we have to click that class button just because we want to write what is effectively a constructor that occurs to us when we are writing an instance method. Its very jarring and breaks your flow to “switch mode” to type one in.

I think Pharo is an environment to experiment with how we think about programming (in Smalltalk as well as other languages) - GTInspector is marvellous, that is something that really shows how thinking about the problem differently can make such a difference. While, I think our standard code browsers are ok - they are stuck in a rut that we need to break. Calypso is a hint at what is possible, but I want GTinspector type thinking more prevalent… with similar types of ideas that inspire us to code better.

Anyway, it seems like I need to take this away and try some experiments by myself.

Tim


> On 23 Jul 2017, at 12:45, Stephane Ducasse <[hidden email]> wrote:
>
> Hi subbu
>
> I used the same metaphor :)
>
> Stef
>
>
> On Sat, Jul 22, 2017 at 4:37 PM, K K Subbu <[hidden email]> wrote:
>> On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote:
>>
>>> The one that stuck out for me (and is actually mentioned in another
>>> thread this week) was the class/instance method difference. They
>>> conceptually understood the difference coming from other languages
>>> but our UI is tricky to understand with the Class button toggle we
>>> have, and if you get methods on the wrong side, like with a test,
>>> it's quite confusing.
>>
>>
>> It is an easy mistake to make and I have often seen this confusion in
>> beginners. With the attention on the methods panel and text input, it is
>> easy to overlook the class toggle button :-(.
>>
>> An easy fix is to switch background color to differentiate between class and
>> instance methods in both code and input panels. A better way would be to use
>> tabs (like in Inspector).
>>
>> BTW, I use the metaphor of toys (objects), moulds (classes) and mould
>> factory (metaclass). A mould is an object from the perspective of the mould
>> maker. Therefore operations on classes are 'methods' from the maker's
>> perspective (note the recursion!).
>>
>>> Anyway - this got me thinking - why do we bother having a toggle in
>>> our UI for this these days? Of course we know there is a class and a
>>> metaclass but given that we have icons for methods now (and also have
>>> a Protocol pane ) why don't we just show all the methods we have in
>>> one list and let you filter them or even see them all? It seems much
>>> easier and way more efficient to rapidly code this way.
>>
>>
>> This perspective comes from the traditional way - code and compile. In
>> Pharo, we code one method at a time and sources are held in an external file
>> and a pointer stored in each method, so displaying all methods in one panel
>> would result in multiple file reads.
>>
>>> The only question then would be how to create methods of the right
>>> type - whether to have a button to create the right template (and put
>>> the  browser code pane in the right context) or whether to indicate
>>> it by convention of the method name when creating it like + new:
>>> aSize etc. (Or even: class new: aSize etc).
>>>
>>> The more I think about it, the more it seems like something we should
>>> consider trying both for making ourselves more efficient (I'll bet
>>> everyone has written a method on the wrong side by mistake) and also
>>> helping newcomers.
>>
>>
>> Such mistakes are part of the learning curve and decrease with time.
>>
>> Regards .. Subbu
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

alistairgrant
Hi Tim,

On Sun, Jul 23, 2017 at 04:04:33PM +0100, Tim Mackinnon wrote:

> I think my thread is misunderstood - I???m not saying change how
> methods work, class methods are fine, instance methods are fine -
> I???m just saying I don???t think its ideal anymore to see them so
> separately in our UI. It was really driven home watching great
> programmers struggle (sure Smalltalk is a bit different - and there
> are many elegant things we have, but class methods are pretty normal
> in many languages) - and I have a similar frustration in that I find
> it a straight jacket that we have to click that class button just
> because we want to write what is effectively a constructor that occurs
> to us when we are writing an instance method. Its very jarring and
> breaks your flow to ???switch mode??? to type one in.

From a purely subjective perspective, having programmed in an
environment where instance and class methods were mixed together
(Python), my opinion is that it makes things more difficult to
understand.

I also think from a theoretical perspective that they should be kept
separate:

Sending an instance method means sending a message to a different object
from sending a class method, so they should be kept separate.

While I agree that visually Nautilus could do a much better job of
distinguishing between instance and class methods, it isn't an argument
in favour of mixing them in a single list.


Cheers,
Alistair


> I think Pharo is an environment to experiment with how we think about
> programming (in Smalltalk as well as other languages) - GTInspector is
> marvellous, that is something that really shows how thinking about the
> problem differently can make such a difference. While, I think our
> standard code browsers are ok - they are stuck in a rut that we need
> to break. Calypso is a hint at what is possible, but I want
> GTinspector type thinking more prevalent??? with similar types of
> ideas that inspire us to code better.
>
> Anyway, it seems like I need to take this away and try some
> experiments by myself.
>
> Tim

Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Attila Magyar
In reply to this post by Tim Mackinnon
Maybe if the protocol list was a tree instead of a list then it would make sense to include the class methods there. This would also make easier to move methods from class side to instance side or vica versa with simple drag and drop (without relying on the refactor/move to class side option).
Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Thierry Goubier
In reply to this post by Tim Mackinnon
Hi Tim,

if you're looking for experiments, you may want to look for the already
existing (or past) experiments on alternative systems browsers.

There are a few floating around, and some of them already have an answer
for what you are considering (change the way class side and instance
side methods are shown). Since you're interested in GTInspector as well,
maybe adding GT extensions to a class could let you experiment on that.

Regards,

Thierry

Le 23/07/2017 à 17:04, Tim Mackinnon a écrit :

> I think my thread is misunderstood - I’m not saying change how methods work, class methods are fine, instance methods are fine - I’m just saying I don’t think its ideal anymore to see them so separately in our UI. It was really driven home watching great programmers struggle (sure Smalltalk is a bit different - and there are many elegant things we have, but class methods are pretty normal in many languages) - and I have a similar frustration in that I find it a straight jacket that we have to click that class button just because we want to write what is effectively a constructor that occurs to us when we are writing an instance method. Its very jarring and breaks your flow to “switch mode” to type one in.
>
> I think Pharo is an environment to experiment with how we think about programming (in Smalltalk as well as other languages) - GTInspector is marvellous, that is something that really shows how thinking about the problem differently can make such a difference. While, I think our standard code browsers are ok - they are stuck in a rut that we need to break. Calypso is a hint at what is possible, but I want GTinspector type thinking more prevalent… with similar types of ideas that inspire us to code better.
>
> Anyway, it seems like I need to take this away and try some experiments by myself.
>
> Tim
>
>
>> On 23 Jul 2017, at 12:45, Stephane Ducasse <[hidden email]> wrote:
>>
>> Hi subbu
>>
>> I used the same metaphor :)
>>
>> Stef
>>
>>
>> On Sat, Jul 22, 2017 at 4:37 PM, K K Subbu <[hidden email]> wrote:
>>> On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote:
>>>
>>>> The one that stuck out for me (and is actually mentioned in another
>>>> thread this week) was the class/instance method difference. They
>>>> conceptually understood the difference coming from other languages
>>>> but our UI is tricky to understand with the Class button toggle we
>>>> have, and if you get methods on the wrong side, like with a test,
>>>> it's quite confusing.
>>>
>>>
>>> It is an easy mistake to make and I have often seen this confusion in
>>> beginners. With the attention on the methods panel and text input, it is
>>> easy to overlook the class toggle button :-(.
>>>
>>> An easy fix is to switch background color to differentiate between class and
>>> instance methods in both code and input panels. A better way would be to use
>>> tabs (like in Inspector).
>>>
>>> BTW, I use the metaphor of toys (objects), moulds (classes) and mould
>>> factory (metaclass). A mould is an object from the perspective of the mould
>>> maker. Therefore operations on classes are 'methods' from the maker's
>>> perspective (note the recursion!).
>>>
>>>> Anyway - this got me thinking - why do we bother having a toggle in
>>>> our UI for this these days? Of course we know there is a class and a
>>>> metaclass but given that we have icons for methods now (and also have
>>>> a Protocol pane ) why don't we just show all the methods we have in
>>>> one list and let you filter them or even see them all? It seems much
>>>> easier and way more efficient to rapidly code this way.
>>>
>>>
>>> This perspective comes from the traditional way - code and compile. In
>>> Pharo, we code one method at a time and sources are held in an external file
>>> and a pointer stored in each method, so displaying all methods in one panel
>>> would result in multiple file reads.
>>>
>>>> The only question then would be how to create methods of the right
>>>> type - whether to have a button to create the right template (and put
>>>> the  browser code pane in the right context) or whether to indicate
>>>> it by convention of the method name when creating it like + new:
>>>> aSize etc. (Or even: class new: aSize etc).
>>>>
>>>> The more I think about it, the more it seems like something we should
>>>> consider trying both for making ourselves more efficient (I'll bet
>>>> everyone has written a method on the wrong side by mistake) and also
>>>> helping newcomers.
>>>
>>>
>>> Such mistakes are part of the learning curve and decrease with time.
>>>
>>> Regards .. Subbu
>>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Thierry Goubier
In reply to this post by Attila Magyar
Le 23/07/2017 à 18:58, Attila Magyar a écrit :
> Maybe if the protocol list was a tree instead of a list then it would make
> sense to include the class methods there. This would also make easier to
> move methods from class side to instance side or vica versa with simple drag
> and drop (without relying on the refactor/move to class side option).

The AltBrowser has been providing that tree view for a few years.

That view is very convenient when you want to see class methods names
while writing an instance method (and the reverse).

Never thought of that need for the drag and drop feature. Maybe I'll add
it (or simply check how it currently behaves for that use case).

Thierry

>
>
>
> --
> View this message in context: http://forum.world.st/Why-do-we-separate-class-instance-methods-in-the-browser-tp4956231p4956439.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Stephane Ducasse-3
In reply to this post by alistairgrant
I agree with you and as a teacher I'm picky on this point :).

Stef

On Sun, Jul 23, 2017 at 6:43 PM, Alistair Grant <[hidden email]> wrote:

> Hi Tim,
>
> On Sun, Jul 23, 2017 at 04:04:33PM +0100, Tim Mackinnon wrote:
>> I think my thread is misunderstood - I???m not saying change how
>> methods work, class methods are fine, instance methods are fine -
>> I???m just saying I don???t think its ideal anymore to see them so
>> separately in our UI. It was really driven home watching great
>> programmers struggle (sure Smalltalk is a bit different - and there
>> are many elegant things we have, but class methods are pretty normal
>> in many languages) - and I have a similar frustration in that I find
>> it a straight jacket that we have to click that class button just
>> because we want to write what is effectively a constructor that occurs
>> to us when we are writing an instance method. Its very jarring and
>> breaks your flow to ???switch mode??? to type one in.
>
> From a purely subjective perspective, having programmed in an
> environment where instance and class methods were mixed together
> (Python), my opinion is that it makes things more difficult to
> understand.
>
> I also think from a theoretical perspective that they should be kept
> separate:
>
> Sending an instance method means sending a message to a different object
> from sending a class method, so they should be kept separate.
>
> While I agree that visually Nautilus could do a much better job of
> distinguishing between instance and class methods, it isn't an argument
> in favour of mixing them in a single list.
>
>
> Cheers,
> Alistair
>
>
>> I think Pharo is an environment to experiment with how we think about
>> programming (in Smalltalk as well as other languages) - GTInspector is
>> marvellous, that is something that really shows how thinking about the
>> problem differently can make such a difference. While, I think our
>> standard code browsers are ok - they are stuck in a rut that we need
>> to break. Calypso is a hint at what is possible, but I want
>> GTinspector type thinking more prevalent??? with similar types of
>> ideas that inspire us to code better.
>>
>> Anyway, it seems like I need to take this away and try some
>> experiments by myself.
>>
>> Tim
>

Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

Tim Mackinnon
In reply to this post by Thierry Goubier
Thierry, i'd forgotten about alt-browser, I recall reading about it a long time ago. I'll check it out as it's sounds like the metaphor I'm thinking about.

The current class/instance toggle just doesn't work well in my opinion - I like the idea of a tree on the protocol pane, that feels like a good use of space.

Anyway, it seems like I'm a bit of a lone voice on this - but that's no problem, I can write something for myself and see how I get on.

If Calypso lives up to what I saw, it sounds like I should be able to mould it happily for me.

Tim

Sent from my iPhone

> On 23 Jul 2017, at 18:25, Thierry Goubier <[hidden email]> wrote:
>
>> Le 23/07/2017 à 18:58, Attila Magyar a écrit :
>> Maybe if the protocol list was a tree instead of a list then it would make
>> sense to include the class methods there. This would also make easier to
>> move methods from class side to instance side or vica versa with simple drag
>> and drop (without relying on the refactor/move to class side option).
>
> The AltBrowser has been providing that tree view for a few years.
>
> That view is very convenient when you want to see class methods names while writing an instance method (and the reverse).
>
> Never thought of that need for the drag and drop feature. Maybe I'll add it (or simply check how it currently behaves for that use case).
>
> Thierry
>
>> --
>> View this message in context: http://forum.world.st/Why-do-we-separate-class-instance-methods-in-the-browser-tp4956231p4956439.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Why do we separate class/instance methods in the browser?

K K Subbu
In reply to this post by Tim Mackinnon
On Sunday 23 July 2017 08:34 PM, Tim Mackinnon wrote:
> I find it a straight jacket that we have to click that class button
> just because we want to write what is effectively a constructor that
> occurs to us when we are writing an instance method. Its very jarring
> and breaks your flow to “switch mode” to type one in.

You raise an important issue here. At the time of subclassing, we
separate variables into instanceVariableNames and classVariableNames,
but not with method selectors :-(. Separate tabs or panels (instance,
class) may be a better way to display these methods.

This quirk pops up in textual mode too. "Foo" alone refers to a class
but "Foo>>bar" refers to a instance side method and we have to use "Foo
class>>bar" to refer to the class side method.

Regards .. Subbu