Nano & mega

ruby-talk
21

Florian Groß wrote:

Trans wrote:

> 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.

22

Florian Groß wrote:

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.

23

Dave Burt wrote:

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

24

The change is afoot.

25

Trans wrote:

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.

26

gsinclair@gmail.com wrote:

Dave Burt wrote:
> 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.

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

···

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

27

Florian Groß wrote:

Trans wrote:

> 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.

28

Nikolai Weibull <mailing-lists.ruby-talk@rawuncut.elitemail.org> writes:

Dave Burt wrote:
> 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.

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

<<quote
If the name of the predicate is formed by adding a p to an existing
name, such as the name of a data type, a hyphen is placed before the
final p if and only if there is a hyphen in the existing name. For
example, number begets numberp but standard-char
begets standard-char-p.
--- http://www.cliki.net/Naming%20conventions >>

It's fairly consistent. (And _p is a good choice for Ruby IMO.)

···

gsinclair@gmail.com wrote:

Nikolai Weibull

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

29

Trans wrote:

Florian Groß wrote:

Trans wrote:

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.

A while back I posted a message talking about some issues I'd found with Mega/Nano ... And it was confirmed by others that at least one of those issues was in fact a bug. They stated that it would be fixed "soon" ... 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.

30

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.