ruby-dev summary 26468-26661

[Takaaki Tateishi]

Here are recent ruby-dev summaries.

Regards,

ruby-dev:26468-26661

[ruby-dev:26468] security error of open-uri when accessing a redirect URL.
Kazuhiko suggested that a security error should not be caused if we access a remote site specified
by an untainted URL string using open-uri in case of $SAFE=1 and the remote server returns redirect
URL. This post set off a discussion about the definition of the taint feature and the security
mechanism, since the definition seems to use undefined ambiguous terms and we don't explicitly
explain when and how we untaint a tainted object.

[ruby-dev:26616] public method
Seki asked about features like 'public', 'private' and 'protected', since He tried to change his
codes in dRuby to check restriction of method calls. In this issue, he proposed a new method like
'send', which can't call private methods. Matz will accept his idea if its appropriate name is decided.

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is summarized
at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Ruby2.0BlockParameterNotation
http://redhanded.hobix.com/inspect/blockAndLambda.html

 

[Navindra Umanee]

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is summarized
at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.

I like it! Looks much more uniform and consistent with function
syntax than {|...| ...}

Thanks for your summary.

Cheers,
Navin.

 

[Daniel Berger]

Takaaki Tateishi wrote:

[ruby-dev:26616] public method
Seki asked about features like 'public', 'private' and 'protected', since He tried to change his
codes in dRuby to check restriction of method calls. In this issue, he proposed a new method like
'send', which can't call private methods. Matz will accept his idea if its appropriate name is decided.

deliver
direct
dispatch
issue
post
connect
transmit
call

Of these, I like "call" the most, but I'm aware of the confusion it
might cause wrt Method#call.

Regards,

Dan

 

[Joel VanderWerf]

Takaaki Tateishi wrote:

[ruby-dev:26616] public method
Seki asked about features like 'public', 'private' and 'protected', since He tried to change his
codes in dRuby to check restriction of method calls. In this issue, he proposed a new method like
'send', which can't call private methods. Matz will accept his idea if its appropriate name is decided.

deliver
direct
dispatch
issue
post
connect
transmit
call

Of these, I like "call" the most, but I'm aware of the confusion it
might cause wrt Method#call.

Regards,

Dan

Or, looking at it from the point of view of the receiver:

handle
respond
receive

 

[Trans]

Instead of another method like send, which does exactly what normally
calling a method does, expect it allows for a variable method name (ie.
symbol or string) why not just allow '.' to dispatch a symbol or
string, instead of just a literal:

obj.:meth

obj."meth"

That would be useless in itself (one can just type 'obj.ameth'), but
now you can use variable interpolation:

m = "meth"

obj."#{m}"

Which does the job. Hmm... scaling this back to just the core
requirement, we could simplify to:

obj#{m}

or

obj#m

That later would require trailing remarks to begin with a space, but
that's a common practice anyway. It's a nice simple notation, but maybe
to "easy" for matz taste?

T.

T.

 

[Trans]

Let me get this straight:

meth(x,y) -> (a,b) {
...
}

instead of

meth(x,y) { |a,b|
...
}

Two extra keystrokes. So why this? B/c Perl6 has it?

What are the critera for this? Is it only for the ambiguity of '|' with
default parameters? Does being able to do this help?

meth(x,y) -> (a,b)
{
...
}

Will we be able to drop the parens?

meth x,y -> a,b {
...
}

And use the word 'with' in place of '->' to go with 'do..end'

meth x,y with a,b do
...
end

Is that the developing picture?

Thanks,
T.

 

[Jim Freeze]

meth(x,y) -> (a,b) {

...
}

What about scope? This notation makes me think that
(a,b)'s scope is not confined within { }.


--=20
Jim Freeze

 

[George Moschovitis]

at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.

I like it! Looks much more uniform and consistent with function
syntax than {|...| ...}

Couldn't agree more. I like this! Perhaps the notation could be further
improved though.

George

 

[Trans]

What about scope? This notation makes me think that

(a,b)'s scope is not confined within { }.

That's a good point.

 

[David A. Black]

Hi --

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is summarized
at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.

I'm not clear on what problem or shortcoming this addresses. Also,
I'm concerned that this amount of multiplied punctuation is going to
detract seriously from "clean" look of Ruby. I know it's not just a
matter of counting punctuation characters. But going from {|x|} to
->(x){} seems like a major move in the "line noise" direction.


David

 

[David A. Black]

Hi --

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is summarized
at the following sites. Now ruby(HEAD) accepts the notation '->(...){...}'.

I like it! Looks much more uniform and consistent with function
syntax than {|...| ...}

I assume you mean method syntax. But why is that important? Until
this new syntax was posted, I'd never heard anyone complain that they
found it hard to recognize {|...| } as a code block. Now there seems
to be a retroactive sentiment in the air that the block syntax is, and
always has been, obscure or garbled.

If uniformity is important maybe def should be redesigned:

def x |a,b,c=1|
end

Then you'd have parallels between blocks and methods:

def == {
end == }
|| == ||

without the -> thing.


David

 

[Jamis Buck]

Hi --

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is
summarized
at the following sites. Now ruby(HEAD) accepts the notation '->
(...){...}'.

I'm not clear on what problem or shortcoming this addresses. Also,
I'm concerned that this amount of multiplied punctuation is going to
detract seriously from "clean" look of Ruby. I know it's not just a
matter of counting punctuation characters. But going from {|x|} to
->(x){} seems like a major move in the "line noise" direction.

IIRC, part of the problem with the || syntax is that it makes it very
difficult to support default parameter values, because the | becomes
ambiguous:

{ |x=5| x+7 }

It's no longer possible to tell if the | marks the end of the
parameter block or a bit-wise OR without reading ahead, possibly to
the end of the block.

- Jamis

 

[Brian Schröder]

On Aug 4, 2005, at 7:31 AM, David A. Black wrote:
=20

Hi --

[ruby-dev:26623] Ruby2.0BlockParameterNotation
Sasada asked about new notation of block parameter. This issue is
summarized
at the following sites. Now ruby(HEAD) accepts the notation '->
(...){...}'.

I'm not clear on what problem or shortcoming this addresses. Also,
I'm concerned that this amount of multiplied punctuation is going to
detract seriously from "clean" look of Ruby. I know it's not just a
matter of counting punctuation characters. But going from {|x|} to
->(x){} seems like a major move in the "line noise" direction.

=20
IIRC, part of the problem with the || syntax is that it makes it very
difficult to support default parameter values, because the | becomes
ambiguous:
=20
{ |x=3D5| x+7 }
=20
It's no longer possible to tell if the | marks the end of the
parameter block or a bit-wise OR without reading ahead, possibly to
the end of the block.
=20
- Jamis
=20
=20
=20

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.

{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this

{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible

regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

 

[David A. Black]

--8323328-314365047-1123165133=:24750
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-314365047-1123165133=:24750"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-314365047-1123165133=:24750
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

IIRC, part of the problem with the || syntax is that it makes it very
difficult to support default parameter values, because the | becomes
ambiguous:

{ |x=3D5| x+7 }

It's no longer possible to tell if the | marks the end of the
parameter block or a bit-wise OR without reading ahead, possibly to
the end of the block.

- Jamis

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.

{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this

{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible

However, { (a) } would be ambiguous. (I don't particularly mind living
without default values in blocks, but I think () wouldn't fly.)


David

--=20
David A. Black
(e-mail address removed)
--8323328-314365047-1123165133=:24750--
--8323328-314365047-1123165133=:24750--

 

[Brian Schröder]

Hi --
=20
On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schr=F6der wrote:
=20

[snip]

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.

{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this

{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible

=20
However, { (a) } would be ambiguous. (I don't particularly mind living
without default values in blocks, but I think () wouldn't fly.)

One could disambiguate this the same way it is done with methods:

{ () (a) }

like in

def anonymus() (a) end

or one could use a differnt pair of symbols, though I don't really like tha=
t.

{ <a, b=3D12> a+b }

Though it's easier to type on a german keyboard. (Thats also one of
the reasons I thoroughly dislike any use of the backslash \. Its just
really inkonvenient to me

regards,

Brian

--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/

 

[Nikolai Weibull]

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.
=20
{ (a, b=3D12) a+b }

I don't understand why we can't retain the use of vertical bars. Is
there some problem with extending their use to be like methods in
general?,
nikolai

--=20
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);}

 

[David A. Black]

--8323328-1500228497-1123169102=:17693
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1500228497-1123169102=:17693"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1500228497-1123169102=:17693
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

Hi --

[snip]

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.

{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this

{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible

However, { (a) } would be ambiguous. (I don't particularly mind living
without default values in blocks, but I think () wouldn't fly.)

One could disambiguate this the same way it is done with methods:

{ () (a) }

like in

def anonymus() (a) end

But then you'd have empty parens all over the place. I guess there
aren't that many paramless blocks, but there are some, like:

Hash.new { () [] } # ugh

or one could use a differnt pair of symbols, though I don't really like t= hat.

{ <a, b=3D12> a+b }

irb(main):005:0> def x(a =3D 1 > 0); p a; end
=3D> nil
irb(main):006:0> x
true




David

--=20
David A. Black
(e-mail address removed)
--8323328-1500228497-1123169102=:17693--
--8323328-1500228497-1123169102=:17693--

 

[David A. Black]

--8323328-220515290-1123169298=:17693
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-220515290-1123169298=:17693"

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-220515290-1123169298=:17693
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

One could disambiguate this the same way it is done with methods:

{ () (a) }

like in

def anonymus() (a) end

(I can't reply to myself because of some weird encoding-related
problem that makes me unable to see my own text.)

I might be wrong in what I said about empty parens, or at least the
example I gave. I guess you could still do:

Hash.new { [] }

and just not have an arglist at all.

I'm still not seeing a bit need for a change in this direction.


David

--=20
David A. Black
(e-mail address removed)
--8323328-220515290-1123169298=:17693--
--8323328-220515290-1123169298=:17693--

 

[Eric Mahurin]

Hi --
=20
On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schr=F6der wrote:
=20

[snip]

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.

{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this

{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible

=20
However, { (a) } would be ambiguous. (I don't particularly mind living
without default values in blocks, but I think () wouldn't

fly.)
=20
One could disambiguate this the same way it is done with
methods:
=20
{ () (a) }

like in
=20
def anonymus() (a) end

That doesn't sound bad and is consistent with "def". But, it
does introduce a backwards incompatibility when you have "{ (a)
}" in existing code.

or one could use a differnt pair of symbols, though I don't
really like that.
=20
{ <a, b=3D12> a+b }

Definitely wouldn't work. Take a look at this:

{ <a, b=3D12 > a+b>2 }

Do you interpret it that way or this way:

{ < a, b=3D12>a+b > 2 }




Here is my proposal:

{ args : code }

Even if when you make the args : optional to preserve
compatibility, I think this would be parsable if you treat the
arg list (possibly with default expressions) like a normal
statment except that the delimiter is ":" instead of ";". This
should work because an arg list is a syntactically valid
statement. i.e.

a=3D1
other=3D[3,4]
a,b=3D2,*other

When the lexer finds a ":" instead of a ";" or newline as the
statement delimiter of first statement, it would treat that as
the arg list.

I like this because it gives the minimal amount of punctuation
for the arg list - one character as a delimiter.



=09
____________________________________________________
Start your day with Yahoo! - make it your home page=20
http://www.yahoo.com/r/hs=20
=20

 

[Brian Schröder]

Hi --
=20
On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schr=F6der wrote:
=20

Hi --

On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schr=F6der wrote:

[snip]

Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.

{ (a, b=3D12) a+b }
is quite clear, and counting nesting parenthesis has to be done in an= y
parser so this

{ (a=3D12, (b,c) =3D [1,2]) a+b**c }
is also possible

However, { (a) } would be ambiguous. (I don't particularly mind living
without default values in blocks, but I think () wouldn't fly.)

One could disambiguate this the same way it is done with methods:

{ () (a) }

like in

def anonymus() (a) end

=20
But then you'd have empty parens all over the place. I guess there
aren't that many paramless blocks, but there are some, like:
=20
Hash.new { () [] } # ugh
=20

Why should you write it like that. If there is no starting ( there is
no argument list. So

Hash.new { [] }

would work in this case.

You'd only need an () if the expression starts with a (.

But maybe there are better options.

regards,

Brian

=20
irb(main):005:0> def x(a =3D 1 > 0); p a; end
=3D> nil
irb(main):006:0> x
true
=20

Ahh, I didn't think of that, and I'm shure theres also a big flaw in
my other thoughts.

regards,

Brian


--=20
http://ruby.brian-schroeder.de/

Stringed instrument chords: http://chordlist.brian-schroeder.de/