[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 '->(...){...}'.
I like it! Looks much more uniform and consistent with function
syntax than {|...| ...}
[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.
[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.
[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
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
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.
[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:
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
···
On Aug 4, 2005, at 7:31 AM, David A. Black wrote:
Hi --
On Thu, 4 Aug 2005, Takaaki Tateishi wrote:
[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.
[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.
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?
Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.
{ (a, b=12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this
{ (a=12, (b,c) = [1,2]) a+b**c }
is also possible
regards,
Brian
···
On 04/08/05, Jamis Buck <jamis@37signals.com> wrote:
On Aug 4, 2005, at 7:31 AM, David A. Black wrote:
> Hi --
>
> On Thu, 4 Aug 2005, Takaaki Tateishi wrote:
>
>
>> [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.
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.
lambda is an anonymous function, so that it requires full syntax of
function/method argument, including optional arguments, keyword
arguments, block arguments etc., not just parallel assignment as in
plain block parameters.
If uniformity is important maybe def should be redesigned:
def x |a,b,c=1|
end
Stop joking.
Unlike others, I have never given uniformity a top priority.
matz.
···
In message "Re: ruby-dev summary 26468-26661" on Thu, 4 Aug 2005 22:38:06 +0900, "David A. Black" <dblack@wobblini.net> writes:
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.
I have no clue about the Bison grammar underlying Ruby, but can't you
"simply" say that if the first token after { is a |, you need to parse
until the next | to get the block parameters?
Of course, you couldn't write { |x = 5|7 | true } then... *I* can live
with that.
I think one of the first things that attracted me to ruby is the {|x>...} syntax. So please leave my happy little blocks alone. Or at least leave them as an option.
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra@yakima-herald.com
509-577-7732
···
On Aug 4, 2005, at 6:38 AM, David A. Black wrote:
Hi --
On Thu, 4 Aug 2005, Navindra Umanee wrote:
Takaaki Tateishi <ttate@ttsky.net> wrote:
[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:
On Thu, 4 Aug 2005, [ISO-8859-1] Brian Schröder wrote:
On 04/08/05, Jamis Buck <jamis@37signals.com> wrote:
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
Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.
{ (a, b=12) a+b }
is quite clear, and counting nesting parenthesis has to be done in any
parser so this
{ (a=12, (b,c) = [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.)
Then why don't we use two different delimiters, e.g. (,) which would
even unify with method declaration.
{ (a, b=12) 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
···
--
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);}
I have no clue about the Bison grammar underlying Ruby, but can't you
"simply" say that if the first token after { is a |, you need to parse
until the next | to get the block parameters?
It would be great if it's possible. But unfortunately I don't have
enough skills to accomplish this using yacc/bison.
Of course, you couldn't write { |x = 5|7 | true } then... *I* can live
with that.
You can always use {|x=(5|7)| true }.
matz.
···
In message "Re: ruby-dev summary 26468-26661" on Fri, 5 Aug 2005 01:14:46 +0900, Christian Neukirchen <chneukirchen@gmail.com> writes:
