I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
David
I do appreciate it, having been slow to test on 1.9.
There is a small bug in the text though:
x = 1
{|x| }
Maybe there should be an "x=3" in the block?
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
I love the idea overall though. Thanks for sharing!
James Edward Gray II
···
On Jan 14, 2009, at 12:40 PM, David A. Black wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
I believe this is something lots of folks want desperately, YHS included.
So please keep the good work up.
A small comment on hash key ordering:
As you said it is insertion order, not update order, thus in the
(unlikely) case that one wants to change that, one
has to delete the key.
h = { a: 42, b: 42 }
h.update a: 42
h --> { a: 42, b: 42 }
vs.
h.delete a:
h.update a: 42
h --> { b: 42, a: 42 }
It seems to be true too that the hash literal is insertion order
preserving, thus the read syntax and write
syntax for hashes seem identical :).
Can anybody confirm this please?
Cheers
R
···
On Wed, Jan 14, 2009 at 7:40 PM, David A. Black <dblack@rubypal.com> wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
--
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov
You might also want to mention (around the point of block-parameters
have def syntax) that procs can take a block now.
The Enumerator stuff is in 1.8.7 already, not sure if it's that
notable. Maybe some things instead about String (#each, Enumerable,
[0], ?a, ...) would be more helpful.
^ manveru
···
On Thu, Jan 15, 2009 at 3:40 AM, David A. Black <dblack@rubypal.com> wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
Everyone please look at it again for those block examples
David
···
On Thu, 15 Jan 2009, Joel VanderWerf wrote:
David A. Black wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
David
I do appreciate it, having been slow to test on 1.9.
There is a small bug in the text though:
x = 1
{|x| }
Maybe there should be an "x=3" in the block?
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
I also think you need to add a section on this error, which seems very
likely to be the first thing programmers encounter in the new m17n code:
Oh yeah.
And this :
require "yaml"
=> true
a = "héhé"
=> "héhé"
b = a.to_yaml
=> "--- !binary |\naMOpaMOp\n\n"
c = YAML.load(b)
=> "h\xC3\xA9h\xC3\xA9"
c << "héhé"
Encoding::CompatibilityError: incompatible character encodings:
ASCII-8BIT and UTF-8
from (irb):8
from /usr/local/bin/irb:12:in `<main>'
Fred
Who is still having trouble with utf-8 in one of his rails models...
···
Le 14 janvier 2009 à 20:14, James Gray a écrit :
--
Aleph-null bottles of beer on the wall, aleph-null bottles of beer.
Take one down and pass it around,
Aleph-null bottles of beer on the wall... (Ingvar the Grey in the SDM)
but a guide summarizing the encoding features and possible problems
would be very helpful.
Thanks
Michal
···
2009/1/14 James Gray <james@grayproductions.net>:
On Jan 14, 2009, at 12:40 PM, David A. Black wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
Double-check your examples in "Block variables scope." It looks like they
may be cut off.
I also think you need to add a section on this error, which seems very
likely to be the first thing programmers encounter in the new m17n code:
No, it's correct as it is. The point is that in ruby 1.8, |x| is
assigned to each time the block is called, and if x existed before the
block, it remains after the block as the last value. This is regardless
of whether you actually use or assign to x inside the block.
$ irb
irb(main):001:0> x = 1
=> 1
irb(main):002:0> [2,3].each{|x| }
=> [2, 3]
irb(main):003:0> x
=> 3
But in ruby1.9, |x| is a local block argument, independent of any local
variable x outside the block.
$ irb19
irb(main):001:0> x = 1
=> 1
irb(main):002:0> [2,3].each{|x| }
=> [2, 3]
irb(main):003:0> x
=> 1
On Thu, Jan 15, 2009 at 3:40 AM, David A. Black <dblack@rubypal.com> wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
You might also want to mention (around the point of block-parameters
have def syntax) that procs can take a block now.
The Enumerator stuff is in 1.8.7 already, not sure if it's that
notable. Maybe some things instead about String (#each, Enumerable,
[0], ?a, ...) would be more helpful.
I'm not really dealing with 1.8.7 in my book (nor much in general).
[0] is a good idea. I do mention in my list that strings aren't
enumerable any more.
I thought the new label: syntax was worth a top-level citation.
That syntax sugar, together with stringy symbols and hashes in hashed order, produce an emergent "named argument" system that makes DSLs much easier to invent on the end of your method arguments.
I just haven't got to the 1.9 sections yet. I will eventually though…
James Edward Gray II
···
On Jan 15, 2009, at 5:18 AM, Michal Suchanek wrote:
2009/1/14 James Gray <james@grayproductions.net>:
On Jan 14, 2009, at 12:40 PM, David A. Black wrote:
Hi --
I know it's not usual to announce blog posts here, but I'm going to
indulge the impulse as the content of this one is something I might
have posted here anyway:
I'm finishing up "The Well-Grounded Rubyist" and am thinking of
writing an appendix with more or less this content, so I thought I'd
run it up the flagpole first.
Double-check your examples in "Block variables scope." It looks like they
may be cut off.
I also think you need to add a section on this error, which seems very
likely to be the first thing programmers encounter in the new m17n code:
I'm not really dealing with 1.8.7 in my book (nor much in general).
The problem with that theory that certain Rails sites (I'm not naming any names!) run 1.8.7 on their servers, for the latest patches, but their developers still use 1.8.6 on their workstations, for all the mature tools...
I thought the new label: syntax was worth a top-level citation.
But that isn't going to break any existing code, and I believe the main
thrust of this article is changes to be wary of - although some aren't
in that category, like def foo(a,*b,c).
I thought the new label: syntax was worth a top-level citation.
It's cool but it doesn't belong on the original list, because it's not
something that might make your existing code fail to work, which is
(mostly what the list is. The mention of ordered hashes is
questionable on those grounds too in fact.
I thought the new label: syntax was worth a top-level citation.
But that isn't going to break any existing code, and I believe the main
thrust of this article is changes to be wary of - although some aren't
in that category, like def foo(a,*b,c).
Yes -- that one and the ordered hash one are a bit out of step with
the overall idea of the post. I guess I just include them among the
new stuff in almost any context out of habit.
It's cool but it doesn't belong on the original list, because it's not
something that might make your existing code fail to work, which is
(mostly what the list is. The mention of ordered hashes is
questionable on those grounds too in fact.
Maybe we need two lists:
- warnings, gotchas, and incompatibilities
- new conveniences and benefits
