Some comments on new 1.9 features
Trans
Nicely done!
Comment on a couple things
1) ;; instead of end
It is possible to use ;; instead of end.
(1..100).inject do |s,x|
s+x
;; # => 5050
class Foo
def foo; "foo" end
;;
Foo.new.foo # => "foo"
What's the rationle here? I'd rather have a punctutation mark for 'do'
(yes, ':' again ;-p)
(1..100).inject: |s,x|
s+x
end # => 5050
Of course could have both:
(1..100).inject: |s,x|
s+x
;; # => 5050
2) Block local variables
Used as follows:
# {normal args; local variables}
d = 2
a = lambda{|;d| d = 1}
a.call()
d # => 2
When a variable is shadowed, ruby1.9 issues a warning:
-:2: warning: shadowing outer local variable - d
Come on. This stinkos. At some point I think you have to give it up and
allow a declaration.
3) Calling Procs without #call/#[]
You can now do:
a = lambda{|*b| b}
(a)(1,2) # => [1, 2]
Note that you need the parentheses:
a = lambda{|*b| b}
a(1,2) # => ERROR: (eval):2: compile error...
I know this has been deprecated, but what causes this not to work
exactly?
4) send doesn't call private methods anymore
ruby-talk:153672 It is still possible to call them with the newly
introduced #funcall method.
class Foo; private; def foo; end; end
Foo.new.funcall(:foo) # => nil
Foo.new.send(:foo) # => ERROR: private method `foo' called for
#<Foo:0xb7e0e540>
No #funcall please, I already have enough methods to make exceptions
for in BlankSlate/BasicObject. Use #instance_send instead. Thank you.
5) Class of singleton classes
singleton class inherits Class rather than its object's class
class X;end; x=X.new; class << x; self < X; end # => true
vs. (1.8)
class X;end; x=X.new; class << x; self < X; end # => nil
Is this example backwards? I'm confused. Please confirm.
6) Class variables are not inherited
ruby-dev:23808
class A; @@a = 1; end; class B < A; @@a end # => ERROR: (eval):1:
uninitialized ...
vs.
class A; @@a = 1; end; class B < A; @@a end # => 1
Love it! Thank you!
T.
nobuyoshi nakada
At Fri, 4 Nov 2005 12:27:09 +0900,
Trans wrote in [ruby-talk:164082]:
> What's the rationle here? I'd rather have a punctutation mark for 'do'
> (yes, ':' again ;-p)
Why do you all want colon to overwork so much? ;)
--
Nobu Nakada
David A. Black
Not all of us -- I'm still in the "conservative about new punctuation"
camp :-)
David
--
David A. Black
dbl...@wobblini.net
Brian Schröder
> Just looking at http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9.
> Nicely done!
>
> Comment on a couple things
>
> 1) ;; instead of end
>
> It is possible to use ;; instead of end.
>
> (1..100).inject do |s,x|
> s+x
> ;; # => 5050
>
> class Foo
> def foo; "foo" end
> ;;
> Foo.new.foo # => "foo"
>
> What's the rationle here? I'd rather have a punctutation mark for 'do'
> (yes, ':' again ;-p)
>
> (1..100).inject: |s,x|
> s+x
> end # => 5050
>
> Of course could have both:
>
> (1..100).inject: |s,x|
> s+x
> ;; # => 5050
>
>
Please don't add ;; thats
1) Sheer uglyness
2) Parses as a noop operation.
Brian
--
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
Dave Burt
David A. Black wrote:
> Hi --
>
> On Fri, 4 Nov 2005, nobuyoshi nakada wrote:
>
>> Hi,
>>
>> At Fri, 4 Nov 2005 12:27:09 +0900,
>> Trans wrote in [ruby-talk:164082]:
>>> What's the rationle here? I'd rather have a punctutation mark for 'do'
>>> (yes, ':' again ;-p)
>>
>> Why do you all want colon to overwork so much? ;)
>
> Not all of us -- I'm still in the "conservative about new punctuation"
> camp :-)
Aren't you the "conservative about most things" camp, David?
Do we all not like ";;"?
Cheers,
Dave
David A. Black
In Ruby development, or in life? :-)
> Do we all not like ";;"?
As a pointless no-op, it's great :-) Is it really being considered as
a synonym for 'end'? I don't understand that at all.
Keith Fahlgren
> Please don't add ;; thats
>
> 1) Sheer uglyness
> 2) Parses as a noop operation.
3) Going to confuse all the people coming from Lisp...
4) Really ugly
Keith
ts
K> 3) Going to confuse all the people coming from Lisp...
perhaps the persons coming from Caml will be happy ...
Guy Decoux
David A. Black
while the remaining parts are likely unreadable without MIME-aware tools.
Ara.T.Howard
an people who don't like to move their fingers off of the
a s d f j k l ;
;-)
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| anything that contradicts experience and logic should be abandoned.
| -- h.h. the 14th dalai lama
===============================================================================
men...@rydia.net
> Please don't add ;; thats
>
> 1) Sheer uglyness
> 2) Parses as a noop operation.
3) Gives me OCaml flashbacks.
(nobody wants that)
-mental
men...@rydia.net
Or confused, because it is similar but different to what it means in
Caml.
-mental
Nikolai Weibull
> class Foo
> def foo; "foo" end
> ;;
> Foo.new.foo # => "foo"
The funny thing about this example is that the whole point of having
";;" be "end" is that you could write
class Foo
def foo; "foo" ;;
end
right? Even so, I really don’t see the point, beyond being able to
write the following:
if something
if something_else
⋮
else
⋮
;;;;
other_statement
Sort of semi-pythonish or something.
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
James Edward Gray II
> The funny thing about this example is that the whole point of having
> ";;" be "end" is that you could write
>
> class Foo
> def foo; "foo" ;;
> end
>
> right?
To save one character?
class Foo
def foo; "foo" end
end
??? That parses today, right?
James Edward Gray II
Dale Martenson
# {normal args; local variables}
d = 2
a = lambda{|;d| d = 1}
a.call()
d # => 2
I think embedding language specific items in comments is silly since
you then have no mechanism to comment them out. Create a directive for
these extensions so that they behave as other parts of the language and
abide by the standard placement rules. Such as, things that are
commented out are not executed and thus ignored.
men...@rydia.net
> class Foo:
> def foo: "foo"
>
> It sounds more expressive than do .. ;;
Serious question: why not permit multi-line bodies this way, by
lining up indention?
Not like Python, but more like Haskell, where using "layout" is
merely optional.
-mental
Trans
The comment was simply that, to indicate what the semi-colon is doing.
It has no function. Nonetheless to me its a good indication of a better
way:
d = 2
a = lambda{|d| local d = 1}
a.call()
d # => 2
Self commenting.
T.
Trans
Trans wrote:
> The comment was simply that, to indicate what the semi-colon is doing.
> It has no function. Nonetheless to me its a good indication of a better
> way:
>
> d = 2
> a = lambda{|d| local d = 1}
> a.call()
> d # => 2
>
> Self commenting.
Sorry, that should be
d = 2
a = lambda{|d| d = 1}
a.call()
d # => 2
Otherwise:
d = 2
a = lambda{|d| share d = 1}
a.call()
d # => 1
T.
Nikolai Weibull
> On Nov 4, 2005, at 10:53 AM, Nikolai Weibull wrote:
> > class Foo
> > def foo; "foo" ;;
> > end
> To save one character?
>
> class Foo
> def foo; "foo" end
> end
Hey! I didn’t say that it was great. I just showed what I thought was
the rationale behind having ;; in Ruby. Don't blame me for its
existance. Anyway, it’s not about saving one character. It’s about
having the ; have a better counterpart than end in this particular
instance. I didn’t say that it’s worth having just for this, though.
Trans
That's interesting. It's quite clean. Which is better because....
I fear the Perly coming-on.
T.
James Edward Gray II
> James Edward Gray II wrote:
>
>
>> On Nov 4, 2005, at 10:53 AM, Nikolai Weibull wrote:
>>
>
>
>>> class Foo
>>> def foo; "foo" ;;
>>> end
>>>
>
>
>> To save one character?
>>
>> class Foo
>> def foo; "foo" end
>> end
>>
>
> Hey! I didn’t say that it was great. I just showed what I thought
> was
> the rationale behind having ;; in Ruby. Don't blame me for its
> existance.
I didn't mean to blame anyone. I was just trying to understand. :)
> Anyway, it’s not about saving one character. It’s about
> having the ; have a better counterpart than end in this particular
> instance.
For a fitting counterpart, I like
class Foo
def foo() "foo" end
end
James Edward Gray II
Dale Martenson
I like the "local" and "share" directives. That would make it clear.
Using too many special characters clutter the code and worsen
readability.
men...@rydia.net
> > Using too many special characters clutter the code and worsen
> > readability.
>
> Yes, something like
>
> { |a, b|
> local a
> share b
> a = 1
> b = 2
> }
>
> would look less weird. However it has the problem that in bigger
> blocks the programmer would need to read back the top of the block
> when he 'forgets' which attributes are local and which shared.
I don't know ... honestly, why can't we just make the block
parameters always block-local? Having to make closure explicit
with share doesn't strike me as very helpful.
There's also a certain "oh, by the way, that variable mentioned
earlier is actually closed over from the enclosing scope" factor.
Not great for comprehensibility.
-mental
Trans
Domenico De Felice wrote:
>
> { |a, b|
> local a
> share b
> a = 1
> b = 2
> }
>
> would look less weird. However it has the problem that in bigger blocks
> the programmer would need to read back the top of the block when he
> 'forgets' which attributes are local and which shared.
They would'nt *have* to be just at the top. You could even do it
conditionally, although usage is subtle:
x = false
a = 1
b = 2
lam1 = lambda { |a, b|
a = 2
b = 4
if x
share b
end
}
lam2 = lambda { b + 1}
lam1.call
lam2.call #=> 3
x = true
lam1.call
lam2.call #=> 5
Closure Magic, yes?
T.
men...@rydia.net
> Trans wrote:
> [CUT]
> > They would'nt *have* to be just at the top. You could even do
> it
> > conditionally, although usage is subtle:
> >
> [CUT]
> > lam1 = lambda { |a, b|
> > a = 2
> > b = 4
> > if x
> > share b
> > end
> > }
> [CUT]
>
> Yeah.. share and local directives could be used like any other
> command.. this usage is nice. It wouldn't be possible using the
> special character (at least not without doing weird things).
> However variables scoping, when statically defined, will still be
> less intuitive than using special char.
Has anyone considered the semantics of share/local and how they
would have to be implemented?
Sure, they look cool, but they'd be a living nightmare in reality...
-mental
Austin Ziegler
> Nikolai Weibull wrote:
> [CUT]
> > The funny thing about this example is that the whole point of having
> > ";;" be "end" is that you could write
> >
> > class Foo
> > def foo; "foo" ;;
> > end
> >
>
> class Foo
> def foo: "foo"
> end
>
>
> class Foo:
> def foo: "foo"
>
..
It sounds too much like Python. Python's syntax is one of the reasons
I don't use Python.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Trans
Would they? Wouldn't 'share' just point the closure's var to the local
one? And 'local' would do just the opposite, (albeit it have to create
the local var in that case). That seems simple enough. Or am I missing
something?
T.
Nikolai Weibull
> It sounds too much like Python. Python's syntax is one of the reasons
> I don't use Python.
Well, the idea was to give everyone the choice of what they wanted to
use, delimited blocks, or indentation blocks. The only issue with this
is that it adds complexity and one’d have to be able to stand reading
both ways of writing code. I read somewhere that the biggest problem
with C is that it doesn’t restrict the syntax enough:
if (<test>)
<statement a>
<statement b>
It’s an accident waiting to happen. And while having an expressive
syntax is sweet and all, it can cause problems that are hard to spot.
I’m certainly not in the “There’s Only One Way To Write It” camp, but
there is some merit to having a simple, unambiguous syntax.
gabriele renzi
>> Do we all not like ";;"?
>
>
> As a pointless no-op, it's great :-) Is it really being considered as
> a synonym for 'end'? I don't understand that at all.
For what I understand: not it was a joke, mostly like GOTO in yarv (hey,
that took me weeks to understand it :)
Eric Hodel
On Nov 4, 2005, at 7:26 AM, Ara.T.Howard wrote:
> On Fri, 4 Nov 2005, ts wrote:
>
>>>>>>> "K" == Keith Fahlgren <ke...@oreilly.com> writes:
>>
>> K> 3) Going to confuse all the people coming from Lisp...
>>
>> perhaps the persons coming from Caml will be happy ...
>
> an people who don't like to move their fingers off of the
>
> a s d f j k l ;
Your keyboard is broken, end is on the center row:
` 1 2 3 4 5 6 7 8 9 0 [ ]
' , . p y f g c r l / = \
a o e u i d h t n s -
; q j k x b m w v z
--
Eric Hodel - drb...@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Brian Schröder
No! I like to standardize badly indented code of other people using my
editors autoindent function. And I also rely on autoindenting while
writing code. So no significant indentation, please.
brian
--
http://ruby.brian-schroeder.de/
Stringed instrument chords: http://chordlist.brian-schroeder.de/
Christian Neukirchen
> Austin Ziegler wrote:
>
>> It sounds too much like Python. Python's syntax is one of the reasons
>> I don't use Python.
>
> Well, the idea was to give everyone the choice of what they wanted to
> use, delimited blocks, or indentation blocks. The only issue with this
> is that it adds complexity and one’d have to be able to stand reading
> both ways of writing code. I read somewhere that the biggest problem
> with C is that it doesn’t restrict the syntax enough:
>
> if (<test>)
> <statement a>
> <statement b>
Using editors that actually can parse what they indent helps a lot
with that. I wouldn't want to code longer pieces without one.
That said, I don't want indentation blocks in Ruby either.
> nikolai
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Kevin Brown
*snip*
> and one’d have to be able to stand reading both ways of writing code.
And learn both. Yuck. That's the problem.
Trans
So can we pudder back to the original example?
10.times: |x|
x
;;
But now someone has said ';;' is a just a joke feature by matz? Is that
true?
T.
Trans
I am not knowledgable enough about the matter to continue. So the
feasibility beyond that is the call of some one with more experience
here, like yourself. If you think it's impossible (or virtually so)
then I have to take your word on it.
T.
Gyoung-Yoon Noh
IIRC, ';;' was stolen from Qu language[1], which Matz also mentioned
with homonym 'qoo', the famous beverage/character.
I don't know why Matz mentioned those simultaneously, but
I can guess as it's just funny, aren't you? ;-)
[1]: http://centrin.net.id/~marc/example.html
Austin Ziegler
<mailing-lis...@rawuncut.elitemail.org> wrote:
> Austin Ziegler wrote:
> > It sounds too much like Python. Python's syntax is one of the reasons
> > I don't use Python.
> Well, the idea was to give everyone the choice of what they wanted to
> use, delimited blocks, or indentation blocks.
IMO, this is not a good idea. Choose one and stick with it. Also IMO,
Ruby came down on the right side of the debate -- indentation blocks
are excessively fragile.
Austin Ziegler
> Austin Ziegler wrote:
> > It sounds too much like Python. Python's syntax is one of the reasons
> > I don't use Python.
> with one-statement blocks. Multi-statements blocks would look the same.
>
> class Foo
> def foo
> a = "foo"
> a
> end
> def bar: "bar"
> end
>
> The indentation of the statement following the colon would be ignored.
> It looks prettier than the double semicolon to me.
> With multilines blocks I can't see any reason to change the do .. end
> syntax.
Ruby permits multiple statements on a single line. Your proposal:
def bar: "bar"
looks unbalanced (because, in fact, it is). It gets worse if you do:
def bar: foo; "bar"
Sorry, but I think that this -- and ;; -- are both bad ideas that
should be dropped.
Nikolai Weibull
> On 11/4/05, Nikolai Weibull
> <mailing-lis...@rawuncut.elitemail.org> wrote:
> > Austin Ziegler wrote:
> > > It sounds too much like Python. Python's syntax is one of the
> > > reasons I don't use Python.
> > Well, the idea was to give everyone the choice of what they wanted
> > to use, delimited blocks, or indentation blocks.
> IMO, this is not a good idea. Choose one and stick with it. Also IMO,
> Ruby came down on the right side of the debate -- indentation blocks
> are excessively fragile.
Thanks for repeating what I said in the rest of my response, which you
have elided here.