On 5/27/09, Roger Pack <rogerpack2005 / gmail.com> wrote:
>> #you can explicitly end just the last scope of something deeply nested.
>> class A
>>   class B
>>     class C
>>       module D
>>         foo
>> end #actually 4 ends
>
>
> I assume that that end is optional, too?

Yes.

> end also doubles as the equivalent for Python's "pass", as well?

Mostly. As I understand it, pass in python is a no-op. End 'stand in',
if you will, for the value of the entire statement it's ending.

(In endless.rb, if you really want a no-op to end your statement, you
should use an (appropriately indented) semicolon.)

> So you can have ends if you want them but they're optional?

You got it. Your end now HAS to be intented right, tho.

> Does it work with {}'s too?

No... seemed a little weird to me to have { without the matching }.
But there's no technical reason why { couldn't be autoended too.

> So the basic rule it uses is that if something returns to the original
> indentation level without being an end, it assumes it should have been
> an end, is that right? (i.e. it *requires* blocks to be at a greater
> indentation level).

Yep.

J Hass wrote:
> Fairly awesome. But I think we should consider keeping the colon, and
> here's why: blocks that are not delimited by a colon at the start
> behave exactly as normal Ruby blocks do, requiring an "end" to close
> them, and more importantly ignoring indentation. That way, existing
> code can be run through the preprocessor when it's "on", and will
> continue to work. And it leaves people to pursue ASCII art with their
> indentation, if they are so inclined.

In my preprocessor, end is still allowed, it's just optional now. So
you can copy and paste from a normal ruby file and not worry. (As log
as the snippet you paste is properly indented.)