Binding precedence for first symbol arguments

[Trans]

I've been thinking about the last thread on module methods and
namespaces, and also the idea of method modifiers. There are times when
I just want one method that does a number of different but related
things. Th obligatory silly example,

class T
def dothis(sym, *args)
when neway
puts "One Way! #{args}"
when :another
puts "Another! #{args}"
end
end
end

t = T.new
t.dothis neway

But we can also do this without the space,

t.dothis:another

IMO that's nice. And allows me to get the effect that I want. What
would be even more convenient thgouh is if this later form, lacking the
space, would give the method precedence, so we could do,

t.dothis:another.upcase

and it would work, executing #dothis before #upcase. Then, also,
secondary parameters could be given without the initial comma. So,

t.dothis neway, 1

could instead be written,

t.dothisneway 1

I do not think this would present any ambiguity to the parser. In fact
I thnk it can be take to any number of initial symbols.

t.dothisneway:twoway:threeway
Where each subsequent symbol is another argument.

T

 

[Eric Hodel]

--Apple-Mail-30-71876799
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

I do not think this would present any ambiguity to the parser. In fact
I thnk it can be take to any number of initial symbols.

t.dothisneway:twoway:threeway
Where each subsequent symbol is another argument.

IthinktheresareasonwhyweputspacesinsentancesToomanywordsinarowmakesforve
rydifficultreading

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-30-71876799
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB/vW/MypVHHlsnwQRApA2AJ44YIk4Q2LVqAIeMB+JhS1ZCkp7QwCgyciq
xKm8Vx8DA2bTQbKUZDyfEeI=
=hKGk
-----END PGP SIGNATURE-----

--Apple-Mail-30-71876799--

 

[Trans]

Eric,

There are the colons. So its not running all-together. Beside yous can
already do it for one symbol:

dothis:another

It already works, and the most common use case would be one initial
symbol. So typically you'll just see things like this:

str.inflectlural

str.format:humanize

str.format:foreign_key true

This format is also more informative in that it tells you the method
(#format) takes a Symbol for the first argument.

How I proposed to do this in the last thread was to use a subclass. Eg.

class String
def inflect
Inflection.new( self )
end
class Inflection
def initialize( delegate )
super
@delegate = delegate
end
def plural
# ...
end
end
end

Thus...

str.inflect.plural

But the addtional object seems expensive in comparisson to a case
statement. Is it?

T

 

[Eric Hodel]

--Apple-Mail-31-74888674
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

Eric,

There are the colons. So its not running all-together. Beside yous can
already do it for one symbol:

dothis:another

Yes... but it encourages bad habits of not putting spaces and commas.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-31-74888674
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB/wGDMypVHHlsnwQRAmR7AKC1huJ9D4kp+t5IuMXc0eIUmU9drACggSOu
JKzhYveCP+11s+jVLY/X+5Q=
=DrIO
-----END PGP SIGNATURE-----

--Apple-Mail-31-74888674--

 

[Ryan Davis]

...There are times when
I just want one method that does a number of different but related
things...

I gotta say wrt your original motivation, to me the need for this
"feature" reeks of bad design. Even ignoring Eric's appeal for
readability/separation of tokens, wanting a single method that "does a
number of different but related things" says to me that maintainability
and comprehensibility is going to be sacrificed in the medium-to-long
run.

It encourages cramming another handler into an existing method when
writing a new method is the appropriate thing to do. Documentation?
Unit testing??? Gah.

And parsability??

You are asking the parser to differentiate var.method:arg.method
between var.methodarg).method and var.methodarg.method) based on
(I'm guessing) the context of already being within a method call.
You'll break _all_ existing code that reads var.method arg.method.

I don't see how, given the original example and the followups, the
benefits outweigh the costs.

 

[Trans]

I gotta say wrt your original motivation, to me the need for this
"feature" reeks of bad design. Even ignoring Eric's appeal for
readability/separation of tokens, wanting a single method that "does a
number of different but related things" says to me that maintainability
and comprehensibility is going to be sacrificed in the medium-to-long

run.

It encourages cramming another handler into an existing method when
writing a new method is the appropriate thing to do. Documentation?
Unit testing??? Gah.

Not necessarily. First off, if one takes this too its ends, one has a
whole lot more clutter in method name space. Moreover, there are a
number of methods that very only by a few variations.

For instance

File.new:ro( filename )

vs.

File.new( filname, FILE::READONLY )

or larger

File.new:creat:trunc:rdwr("newfile", 0644)

vs.

File.new("newfile", File::CREAT|File::TRUNC|File::RDWR, 0644)

And parsability??

You are asking the parser to differentiate var.method:arg.method
between var.methodarg).method and var.methodarg.method) based on
(I'm guessing) the context of already being within a method call.

No, just on whether there's a space or not. Is there a third valid
interpetation that would make this impossible?

You'll break _all_ existing code that reads var.method arg.method.

? That should run jut as it does now as 'var.method(arg.method)'. You
must be trying to point out something else?

I don't see how, given the original example and the followups, the
benefits outweigh the costs.

Perhaps. It's just something that I have come across as a possibility.
At the moment I am preferring the use of an intermediary method, a
"methobox" in effect.

class String
def format
Format.new( self )
end
class Format
def self ; word ; end
def initialize( word )
@self = word
end
def jossle
r = ''
@self.each_char{ |c| r << ( c[0] % 2 == 0 ? c.upcase :
c.downcase ) }
r
end
end
end

"apple".format.jossle #=> aPpLe

In my mind, this sure beats the pants off of messing with modules and
keeps the namespace nice and clean and organized. Futher more, lower
routines that are considered more common can be "aliased" upward.
class String
def jossle
format.jossle
end
end

T

 

[Martin DeMello]

I gotta say wrt your original motivation, to me the need for this
"feature" reeks of bad design. Even ignoring Eric's appeal for
readability/separation of tokens, wanting a single method that "does a
number of different but related things" says to me that maintainability
and comprehensibility is going to be sacrificed in the medium-to-long
run.

http://cgi.bramwell.plus.com/krblog/2004/07/avoid_boolean_p.html is a
thought provoking read on adding-to-the-api versus adding-to-the-arglist

martin

 

[Trans]

Thanks martin,

Perhaps Kevin Rutherford is right. But her present such a limited use
case: a single true/false parameter. On the end of the spectrum is most
commonly used form of method invocation in the world, the Shell. And it
does not follow this. If it did we's have many more tools with names
like:

gzip
ungzip
gzip_force
ungzip_force
gzip_help
gzip_test
gzip_verbose
ungzip_verbose
gzip_force_verbose
ungzip_force_verbose
....
gzip_force_verbose_recusrvie_noname
....

Symbolic flags go a long way toward easing use for human beings. The
conditions they form within the function, while perhaps less efficient
in exectution, are not, as suggested, antithetical to good programming
as they have an avantage in creating DRYer code.

T

 

[Aredridel]

http://cgi.bramwell.plus.com/krblog/2004/07/avoid_boolean_p.html is a
thought provoking read on adding-to-the-api versus adding-to-the-arglist

Hm. I think that in a language where you can't have any keyword-like
arguments, that makes total sense.

What T. is suggesting, I think, makes the API more verbose, but lets the
implementation treat it as booleans. . . which makes a lot of sense to
me. I've always hated code that had various factored out private helper
methods, or a large API of very similar functions. I can't see why

def do_foo_with_arg(a)
f = Foo.new
f.arg = a
f.run
end

def do_foo
f = Foo.new
f.run
end

is any better than

def do_foo(arg = nil)
f = Foo.new
f.arg = arg if arg
f.run
end

unless you needed to override the parts in a subclass. The second seems
far more succinct, though the example's nearly pathologically short.

For some reason, T.'s proposal makes a lot of sense to me -- I think of
whitespace as significant in that way already (the "foo.bar (baz)" vs
"foo.bar(baz)" distinction in the current parser makes total sense to
me) and I really like the way File.open:ro(filename) looks, and I would
enjoy an implementation that let me define it as

def File.open(file, flags)

Or even, in a more overloaded method (line noise! Gasp!)

def frob(arg, arg2, *args, **flags, &block)

Or, assuming it wasn't totally confusing to have some symbol overlap,
@flags.

Ari