nano & mega

[Trans]

But also, you do not need to bother with them at all. There are a
couple of options for forgetting about the whole thing. The simplest
is:

require 'nanosys'

Then you can use the actual punctuation all you want --and w/o any
special require method:

require 'nano/array/[]='

But I'd rather see this based on meaningful, easy to understand naming
scheme under the hood.

Luckily, I have already mapped the special method names. Let me use the
look up table from extract.rb:

{
"+" => "op_plus",
"-" => "op_minus",
"+@" => "op_plus_self",
"-@" => "op_minus_self",
"*" => "op_mul",
"**" => "op_pow",
"/" => "op_div",
"%" => "op_mod",
"<<" => "op_lshift",
">>" => "op_rshift",
"~" => "op_tilde",
"<=>" => "op_cmp",
"<" => "op_lt",
">" => "op_gt",
"==" => "op_equal",
"<=" => "op_lt_eq",
">=" => "op_gt_eq",
"===" => "op_case_eq",
"=~" => "op_apply",
"|" => "op_or",
"&" => "op_and",
"^" => "op_xor",
"[]" => "op_fetch",
"[]=" => "op_store"
}

I'd suggest using foo_bang for foo!, foo_p for foo? and foo_setter for foo=.

Hi Florian,

While I agree that this is a well thought out transform, I wonder, what
is the motivation exactly? The URI transform allows the computer to
deal with the methods in a straightforward manner, such as in the
NanoSystem metainfo and it's capabilities like:

String.use :[]=

Also I have an interesting experiment using method_missing to
automatically require nano-methods. Of course I can still do those
things with the above, but I would noless have to run it through your
transform rather then URI's. So there's still a need for a require_esc
and require_nano, etc.

BTW, I wonder, have you enumerated every possibility? Also there are
some odd looking fringe cases like: '__send__!' => '__send___bang'. At
worst though, what if a method is actually called #foo_p? Hmm... now
that I think of it, there is already a method called 'attr_setter'.
I'll give it some more consideration though. In the mean time I added
two new kernel methods #uri and #unuri. So there's another way:

require uri('nano/array/[]=')

Additionlly I created an exectuable called uri which makes it easy to
look up on the command line:

uri '+@'
%2B%40

And for reference, here's a chart:

{
"!" => "%21"
"%" => "%25"
"&" => "%26"
"*" => "%2A"
"+" => "%2B"
"-" => "%2D"
"/" => "%2F"
":" => "%3A"
"<" => "%3C"
"=" => "%3D"
">" => "%3E"
"?" => "%3F"
"@" => "%40"
"[" => "%5B"
"]" => "%5D"
"^" => "%5E"
"`" => "%60"
"|" => "%7C"
"~" => "%7E"
}

T.

 

[gsinclair]

Why foo_p? What's the p? ZenSpider's ZenTest suggests foo_eh. I could see
maybe _q or _bool. Also I'd prefer _set to _setter.

P is for "predicate". It's a Lisp or Scheme thing; can't remember
which.

Gavin

 

[Nikolai Weibull]

P is for "predicate". It's a Lisp or Scheme thing; can't remember
which.

Common Lisp. Scheme uses '?'. Common Lisp isn't 100% consistent,
though, as it uses both '-p' and just 'p' as suffixes for predicate
functions. Either way, using 'p' is the best suggestion so far,
nikolai

 

[Trans]

Luckily, I have already mapped the special method names. Let me use the
look up table from extract.rb:

{
"+" => "op_plus",
"-" => "op_minus",
"+@" => "op_plus_self",
"-@" => "op_minus_self",
"*" => "op_mul",
"**" => "op_pow",
"/" => "op_div",
"%" => "op_mod",
"<<" => "op_lshift",
">>" => "op_rshift",
"~" => "op_tilde",
"<=>" => "op_cmp",
"<" => "op_lt",
">" => "op_gt",
"==" => "op_equal",
"<=" => "op_lt_eq",
">=" => "op_gt_eq",
"===" => "op_case_eq",
"=~" => "op_apply",
"|" => "op_or",
"&" => "op_and",
"^" => "op_xor",
"[]" => "op_fetch",
"[]=" => "op_store"
}

I'd suggest using foo_bang for foo!, foo_p for foo? and foo_setter for foo=.

I've given this some more thought. If I do this, I could enforce a rule
that says no nono-method is to start with 'op_'. While that's skirting
potential clash, I think it would be okay. But I still have two others
problems.

How to deal with ?, !, =. That's a bit trickier, as its hard to enforce
a rule related to those. Things like '_p', '_setter', have too great a
chance for some actual method clash. So I have to figure something else
out for that.

Also, I have to distinguish class methods. Right now I do it with '::'
prefix, which under URI translation if '%3A%3A'. What will I do here?
"class_" prefix desn't work for the same reason as the above.

Also, am I overlooking any other potential pitfalls?

So here's an idea. While Ruby techinically allows any non-blank string
as a method name (ie. define_method "whatever you want!@#$%") I am as
sure as I can ever be that I will never use such a thing in Nano. Given
this, I need only worry about the literal cases. Now in file systems
the dash characeter '-' is pretty much unviserally accepted, but it's
not allowed in literal method names (expect for the op) So what if I
use that characeter as a distinguishing element? Would that work for
you?

So foo-bang, foo-p, foo-set, and class-foo, plus I might as well do:

{
"+" => "op-plus",
"-" => "op-minus",
"+@" => "op-plus-self",
"-@" => "op-minus-self",
"*" => "op-mul",
"**" => "op-pow",
"/" => "op-div",
"%" => "op-mod",
"<<" => "op-lshift",
">>" => "op-rshift",
"~" => "op-tilde",
"<=>" => "op-cmp",
"<" => "op-lt",
">" => "op-gt",
"==" => "op-equal",
"<=" => "op-lt-eq",
">=" => "op-gt-eq",
"===" => "op-case-eq",
"=~" => "op-apply",
"|" => "op-or",
"&" => "op-and",
"^" => "op-xor",
"[]" => "op-fetch",
"[]=" => "op-store"
}

I thik also I'd like to reduce all of them to a single dash if
reasonably possible, which would change a few of them.

What do you think of this?

Thanks,
T.

 

[Trans]

The change is afoot.

 

[Florian Groß]

So foo-bang, foo-p, foo-set, and class-foo, plus I might as well do:

{
"+" => "op-plus",
"-" => "op-minus",
"+@" => "op-plus-self",
"-@" => "op-minus-self",
[...]
}

I thik also I'd like to reduce all of them to a single dash if
reasonably possible, which would change a few of them.

What do you think of this?

Let me give a late okay to this. My mapping was initially for going from
method names to names for test methods so using - was no option for me.
It makes sense here and helps with avoiding collisions.

What was the motivation for this? Sure: It is mostly transparent if you
use the custom require or escaping functionality you provide, but what
if I want to do a patch for a file or have a look at the implementation
of something? Here it really helps if the files are intuitively named.

 

[Trans]

So foo-bang, foo-p, foo-set, and class-foo, plus I might as well do:

{
"+" => "op-plus",
"-" => "op-minus",
"+@" => "op-plus-self",
"-@" => "op-minus-self",
[...]
}

I thik also I'd like to reduce all of them to a single dash if
reasonably possible, which would change a few of them.

What do you think of this?

Let me give a late okay to this. My mapping was initially for going from
method names to names for test methods so using - was no option for me.
It makes sense here and helps with avoiding collisions.

Thank you, Florian! And yet your luck perhaps is even better. I decided
just to be a little bit loosey-goosey on this last issue and simply
remove any trailing punctuation marks. Yes, that means #first? and
#first! are in the same file, first.rb. While not ideal, this bit of a
fudge seems reasonable and managable. In many cases it is actually
preferable (eg. string/dresner and string/dresner!) And that way I can
use the 'op_' as a reserved prefix. For class methods I put those in a
tertiary subdir 'self', eg. 'nano/file/self/read_list' (think "def
self.read_list")

And btw I'm currently using your op-to-english table as is.

What was the motivation for this? Sure: It is mostly transparent if you
use the custom require or escaping functionality you provide, but what
if I want to do a patch for a file or have a look at the implementation
of something? Here it really helps if the files are intuitively named.

Thanks, I agree. While I had tried english names before, it didn't work
b/c I did not use consistant names. Your consitant naming scheme works
well. I have already found it easier to use.

You can look foward to the change in the next release, which should be
farily soon.

Thanks again,
T.

 

[Jeff Wood]

--------------000307010004030605000400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Florian Gro=DF wrote:
=20

Trans wrote:

=20

So foo-bang, foo-p, foo-set, and class-foo, plus I might as well do:

{
"+" =3D> "op-plus",
"-" =3D> "op-minus",
"+@" =3D> "op-plus-self",
"-@" =3D> "op-minus-self",
[...]
}

I thik also I'd like to reduce all of them to a single dash if
reasonably possible, which would change a few of them.

What do you think of this?
=20

Let me give a late okay to this. My mapping was initially for going fro= m
method names to names for test methods so using - was no option for me.
It makes sense here and helps with avoiding collisions.
=20

Thank you, Florian! And yet your luck perhaps is even better. I decided
just to be a little bit loosey-goosey on this last issue and simply
remove any trailing punctuation marks. Yes, that means #first? and
#first! are in the same file, first.rb. While not ideal, this bit of a
fudge seems reasonable and managable. In many cases it is actually
preferable (eg. string/dresner and string/dresner!) And that way I can
use the 'op_' as a reserved prefix. For class methods I put those in a
tertiary subdir 'self', eg. 'nano/file/self/read_list' (think "def
self.read_list")

And btw I'm currently using your op-to-english table as is.

=20

What was the motivation for this? Sure: It is mostly transparent if you
use the custom require or escaping functionality you provide, but what
if I want to do a patch for a file or have a look at the implementation
of something? Here it really helps if the files are intuitively named.
=20

Thanks, I agree. While I had tried english names before, it didn't work
b/c I did not use consistant names. Your consitant naming scheme works
well. I have already found it easier to use.

You can look foward to the change in the next release, which should be
farily soon.

Thanks again,
T.


=20

A while back I posted a message talking about some issues I'd found with=20
Mega/Nano ... And it was confirmed by others that at least one of those=20
issues was in fact a bug. They stated that it would be fixed "soon" ...=20
I haven't heard anything since, and haven't seen any updates to the gem .=
..

Any ideas when the next release of Mega/Nano will be coming around?

j.


--------------000307010004030605000400--

 

[Trans]

Hi Jeff.

Except for some additional tests I need to write, the next version of
Nano is pretty much ready. I've been putting it off until I finished
some work I'm doing on Mega. But it shouldn't take much longer --with a
little luck by the end of this week.

T.