Prev: swapping regex libraries
Next: what about allowing to specify, which end belongs to which start?
From: Ryan Davis on 9 Jul 2010 15:17

On Jul 9, 2010, at 12:05 , Jan Lelis wrote:

> I've recently come across a pretty common situation in Ruby:
>
> end
> end
> end
>
> After those parts, you often don't know, where exactly you have to
> continue.
>
> So what about allowing to specify, which end belongs to which start?
> I've thought about something like this:
>
> end|do
> end|if
> end|def
>
> or
>
> end~do
> end~if
> end~def
>
> or
>
> end:do
> end:if
> end:def
>
> If you specify it, and it does not match, the compiler throws an error.
> Of course, you can always omit it to have the normal behaviour, but you
> are encouraged to often "document", which end belongs to which block
> (and you do yourself a favour in these nested situations).
>
> What do you think about it?

I think if you have so many ends that you need to extend the syntax then you're doing something wrong to begin with (no pun). I try to make all my methods short when I can, and I use judicious use of extra returns to separate code into paragraphs to further help. I think this type of syntax extension would further encourage large bad codes.


From: Jan Lelis on 9 Jul 2010 20:42
> I think "encouraged" is the wrong word. Your extension would _force_
> the user to use this idiom (which I personally find too verbose).
Also,
> your solution does not help if you nest the same type of control flow
> statement. If you want to document nesting you can do that today
> already (and some people actually do it). [...]

I thought more of: use it seldom (it's too verbose), only at spots,
where there are, e.g. at least 3 "end"s... The problem with documenting
is that the interpreter cannot detect false order, etc.

> I think if you have so many ends that you need to extend the syntax
> then you're doing something wrong to begin with (no pun). I try to
> make all my methods short when I can, and I use judicious use of
> extra returns to separate code into paragraphs to further help. I
> think this type of syntax extension would further encourage large bad
> codes.

Yes, the syntax would to have be extended... but that's no reason why it
cannot be good...
Unfortunately, it is not always possible (or good) to keep the code
short and flat...

> Plus, editors with auto indentation and code completion usually help.
I
> personally have made it a habit to always write the opening and
closing
> construct before I fill in the body. That way you can work pretty
well
> even if your editor does not have fancy features.

Yes, but it is not only about the writing, also about the reading or
refactoring of code.

_____
J-_-L


From: Ryan Davis on 10 Jul 2010 01:45


On Jul 9, 2010, at 5:42 PM, Jan Lelis <prog(a)janlelis.de> wrote:

> Unfortunately, it is not always possible (or good) to keep the code
> short and flat...

Wrong wrong wrong. I cannot disagree more.

From: Jan Lelis on 10 Jul 2010 09:32
On Sat, 2010-07-10 at 14:45 +0900, Ryan Davis wrote:
>
> On Jul 9, 2010, at 5:42 PM, Jan Lelis <prog(a)janlelis.de> wrote:
>
> > Unfortunately, it is not always possible (or good) to keep the code
> > short and flat...
>
> Wrong wrong wrong. I cannot disagree more.
>

I mean, of course, you should try to keep it short... but I think the

end:do
end:if
end:def

is not too much nested, in most cases. I do not want to put every block
or if into its own method...

_____
J-_-L


From: Eleanor McHugh on 10 Jul 2010 11:10
On 9 Jul 2010, at 20:05, Jan Lelis wrote:
> If you specify it, and it does not match, the compiler throws an error.
> Of course, you can always omit it to have the normal behaviour, but you
> are encouraged to often "document", which end belongs to which block
> (and you do yourself a favour in these nested situations).
>
> What do you think about it?

Jan, it's not in Ruby's nature to hold your hand so whilst I can't see any particular technical reason for having such an _optional_ syntax extension, I'd be uncomfortable with code that relied upon them.

In any event the underlying problem you're describing is one which in the vast majority of cases is a code smell and is best dealt with by aggressive refactoring. Move the inner loops into their own method calls, or write your outer-loop logics as a method taking a block and drive iteration/whatever that way. The resulting code will be much easier to read and maintain, and the generality will improve your code reuse options.


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason



 |  Next  |  Last
Pages: 1 2 3 4
Prev: swapping regex libraries
Next: what about allowing to specify, which end belongs to which start?