https://forum.world.st/Why-do-we-separate-class-instance-methods-in-the-browser-tp4956231p4956440.html
existing (or past) experiments on alternative systems browsers.
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.
> 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
>>>
>>
>
>
>