Posted by
K K Subbu on
Jul 22, 2017; 2:18pm
URL: https://forum.world.st/Why-do-we-separate-class-instance-methods-in-the-browser-tp4956231p4956244.html
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