Intriguing idea, but completely ad-hoc, and potentially confusing and
unreadable. Especially if someone were to apply it with the “Few small
classes per method” style of programming, or any similar meta contexts.
What
exactly would the ``<’’ close then? The innermost or the outermost
class?
What about a module used as a namespace containing several spaces
classes in
a single source file?
A magic “end almost everything for given values of almost everything”
would be
just repeating the constant lookup issue all over again. Not necessarily
a
problem to bite you in the majority of cases, but another bit of syntax
most
people can’t really remember how it really works.
I might also be horribly, horribly wrong. In that case, ignore me as
usual.
David V.
DÅ?a Sobota 04 Február 2006 08:13 Luke Duncalfe napÃsal:
Me too. I always say that the Ruby all control
structures always ends on the end. It’s easier and
simpler. If-(endif-fi-etc) makes some confusion when
you work with a couple of languages. Ends are cool.
And, talking about indentation, with we work with tab
we’ll have another dilema: tabs or spaces, as Python.
Yes I really like the end statements, and they make it easier for
beginners. It’s possible to support both indenting and end statements
(i.e. support one mode or the other), and you don’t need python’s
redundant and unnecessary colons. I implemented this myself in a
parser. I don’t think it is appropriate for ruby, however.
What would be even better would be to allow optional labels after end
statements, such as “end class”, “end def”, so the parser can catch
more errors.
I’ve implemented this as well in a separate project.
Instead of voting for multiple “end xxx”, I would like to suggest that
more pairs/keyword than “do … end” and “{ … }” can be used to define
a block.
For examples:
begin … end
is … end
then … end
Because sometimes, the correct word is not “do”. For examples to define
mapping I’d like to do
Brain.learn :cooking is
…
end
rather having “do” there.
It also simplify many semantic in Ruby for example. defining
class/method could be viewed as a method that takes a block. But “do”
wouldn’t make sense there, but:
class Person is #<<< just a method taking a block
def say(message) is #<<< Don’t know :S
…
end
end
It may make Ruby code reflect more closely to what I am thinking in
word.
I’ve implemented this as well in a separate project.
wouldn’t make sense there, but:
class Person is #<<< just a method taking a block
def say(message) is #<<< Don’t know :S
…
end
end
It may make Ruby code reflect more closely to what I am thinking in
word.
To extends it further, may be a syntax for a method to specify what
word they want to use instead of “do”. It must be possible to still use
“{}” or “do/end”, just that another word can also be used instead.
For example of where “do” isn’t the right word (at least for me), look
at Markably and Ezra’s Where Plugin.
I think I like this. If it were an RCR, I just might vote for it.
But I would want two things:
Not too much proliferation, please. “is” and “do” are enough.
Let’s make it clear that “is/end” and “do/end” shall behave
exactly the same way. No subtle differences, please.
This almost makes me want an alias_keyword… but that would probably
cause more problems than it would solve.
I definitely wouldn’t want that. I really feel that “less is more”.
Less keywords, not more, will result in less confusion.
I would love the is|do aliasing. Expressive code should be a primary
concern.
It also seems to be in line with the philosophy of the ruby libraries,
the
if/unless constructs, etc…
On Tue, Feb 07, 2006 at 12:38:20AM +0900, Lionel T. wrote:
} Mark V. a ?crit :
} > On 2/3/06, Thomas K. [email protected] wrote:
} >
} >>* On Feb 3 13:07, MenTaLguY ([email protected]) wrote:
} >>
} >>>For what it’s worth, I also strongly dislike it. It was one of my
} >>>least favorite features of OCaml’s syntax.
} >>>
} >>>But here, the biggest problem is that (relative to other block
endings
} >>>in pretty much any language I can think of), it’s much harder to
} >>>visually count ;;s if they are squashed together as in your
example.
} >>>
} >>>I think this is largely because there aren’t any visual cues to the
} >>>boundary between tokens. The gap between two ;s within the same ;;
and
} >>>the gap between two ;s in adjacent ;; aren’t visually
distinguishable.
} >>
} >>I was going to write my own post, but it seems MenTaLguY did it for
me!
} >>
} >>I am in total agreement; semicolons are an ugly way to end sections.
} >>Curly braces I have a much easier time with.
} >
} >
} > I’m not a fan of the curly braces, but if we do end up using them, I
} > hope we don’t allow this.
} >
} > def some_method(args)
} > # some code
} > }
} >
} > If we’re going to use them, I think they need to be matched, so a {
} > should appear at the end of the method argument list.
}
} def some_method = ->(args) {
} # some code
} }
}
} :-p
You appear to be joking, but I’d kind of like that. I’d love to be able
to
enclose all my scopes in curly braces and never type do/is/end at all.
I’m sure this comes of a C-syntax-centric worldview, but I’d love it.
The only word of caution that I would wish to express here is:
NOT EVERYONE HAS ENGLISH AS A FIRST LANGUAGE!!!
It may be expressive in English but for some people it is just an
arbitrary
sequence of symbols.
that applies to all keywords and libraries as well.
In my experience english is the de-facto standard when writing code.
Doing otherwise also creates endless problems when you need to hire
consultants in the international market.
I use native languages only when dealing with concepts that are very
specific to that language (usually legalese or bureaucrat-speak).
Another good place where to use the native language would be
customer-facing
tests, I guess.
What do you think about those "end"s? Do you REALLY like them?
Will Ruby-2 offer an alternative? Well, maybe not “indentation” but
will another solution be available?
I hope that the mistake that Python makes isn’t repeated in Ruby 2.0.
I prefer explicit – and more flexible – than implicit and
inflexible.
are you citing line 2 of “the zen of python”[1] consciously?
Doubtful. I don’t follow Pythonistas. However, if they are at all
serious about it, the irony involved in their own failure to be
explicit is delicious.
In other words, I really do like the ends.
I always have the feeling that there could be something better than
ends, but untile I find it I’m happy with them.
I’ve never had that feeling. I’ve programmed in too many different
programming languages to feel that there’s anything “wrong” with them.
I can’t help but think that I am not the only one here that thinks this
is, to put it kindly, silly.
Suggestions:
;; - probably the worst idea I can think of. Too easy to miss, looks
like a typo to a C, C++, or Java programmer
end - this is VB-ish … gives me the shakes just to look at
it!
{} - as a C/C++/etc developer, I can read this but it WILL engender
brace placement wars, probably started by me!
I was attracted to ruby in part BECAUSE of the simple syntax. I’ve not
had one problem with the end construct, ever. Just use indentation,
which you should anyway for general clarity, and its done.
“Serdar Kiliç” [email protected] wrote in message
news:[email protected]…
Honestly, I prefer ENDs to indentation, I prefer curly braces to ENDs.
But how about something like this:
def foo @var
}
Oooh. Now I found quite attractive. It’s like a single bookend keeping
things upright between itself and the wall.
It’s easier and