When we create a missing method in debugger - why does it end with a dot?

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

When we create a missing method in debugger - why does it end with a dot?

Tim Mackinnon
I am looking at porting my missing class creation code into Pharo 7, and I notice there is a DynamicMessageImplementor that does this for methods - but I’m wondering why when we create a missing method with ‘self souldBeImplemented.’ with a trailing “.”?

The Smalltalk style guide normally says the last statement shouldn’t have a dot - and I notice some recent cleanups removed some dots on methods (presumably the formatter).

This is a bit of a special case as the intent is to replace that method - but shouldn’t we create without the dot to set a good example anyway?

If so, I can include that change in my pr.

Tim
Reply | Threaded
Open this post in threaded view
|

Re: When we create a missing method in debugger - why does it end with a dot?

Marcus Denker-4


> On 30 Aug 2018, at 06:36, Tim Mackinnon <[hidden email]> wrote:
>
> I am looking at porting my missing class creation code into Pharo 7, and I notice there is a DynamicMessageImplementor that does this for methods - but I’m wondering why when we create a missing method with ‘self souldBeImplemented.’ with a trailing “.”?
>
> The Smalltalk style guide normally says the last statement shouldn’t have a dot - and I notice some recent cleanups removed some dots on methods (presumably the formatter).
>
> This is a bit of a special case as the intent is to replace that method - but shouldn’t we create without the dot to set a good example anyway?
>
> If so, I can include that change in my pr.
>

I think there are both schools around… with some preference of no . at the end.

Sometimes I think that a system that would have a good pretty printer and *always* pretty print would be nice: you would configure this once, and all code
would be shown in your “best readable” style…

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: When we create a missing method in debugger - why does it end with a dot?

jtuchel
Agreed, Marcus.

In case of the trailing dot it is not only about beauty, however. Most people who favor the dot think about the poor developer who comes after them and needs to append new statements to existing methods.

Some people would say: what’s the deal here?

The deal is that syntax highlighters and autoconpleters tend to fail for the  new statements, and most certainly your method change will not compile just because of that missing dot. Again: oust a few seconds to understand what’s wrong, easy to fix and no big deal. But it costs brain capacity that could be spent better.

Not sure a „virtual dot“ visually added by a pretty printer would help here. I’m afraid it would make things worse, unless it is intelligent enough to know when to „materialize“ that virtual dot (I.e. add it to the method whenever somebody writes code after the last statement.

Joachim


...ain’t it funny this little dot is back in discussions decades after it was fought over and cost lives back in the 90ies? Seems we’re not over it yet

> Am 30.08.2018 um 09:59 schrieb Marcus Denker <[hidden email]>:
>
>
>
>> On 30 Aug 2018, at 06:36, Tim Mackinnon <[hidden email]> wrote:
>>
>> I am looking at porting my missing class creation code into Pharo 7, and I notice there is a DynamicMessageImplementor that does this for methods - but I’m wondering why when we create a missing method with ‘self souldBeImplemented.’ with a trailing “.”?
>>
>> The Smalltalk style guide normally says the last statement shouldn’t have a dot - and I notice some recent cleanups removed some dots on methods (presumably the formatter).
>>
>> This is a bit of a special case as the intent is to replace that method - but shouldn’t we create without the dot to set a good example anyway?
>>
>> If so, I can include that change in my pr.
>>
>
> I think there are both schools around… with some preference of no . at the end.
>
> Sometimes I think that a system that would have a good pretty printer and *always* pretty print would be nice: you would configure this once, and all code
> would be shown in your “best readable” style…
>
>    Marcus
>
>
>