Does an Array#apply make any sense at all?

ruby-talk
21

* <dblack@rubypal.com> (16:48) schrieb:

That is true for Array#delete. delete is always destructive, there is no
need to flag that.

And push, pop, <<, concat, replace, clear...

Which all have to be modifying. With the exception of concat. (The Unix
cat command isn't modifying.)

It should simply be clear from the name[0] if a method is destructive.
Often you need the ! for that, in some cases it's obvious without the !.

I guess I take my cue from the Ruby core/standard language, where
there's no use of !, as far as I know, except to distinguish a
"dangerous" method from its non-dangerous partner.

That's because of the completeness of the library. Whenever there can be
a non-modifying partner, there is one.

When you just define a modifying method, is not right to name it without
a ! just because you choose not to define a non-modifying version.

What if some other developer wants to add the non-modifying version?
He would have to rename your version.

mfg, simon .... l

22

Seems like a bad idea to me. Case sensitivity is not a property of the platform; it is a property of a given file system. It's easy to have some case sensitive and some case insensitive file systems on many platforms, including Mac OS and Windows.

Besides, there is more to pathname equivalence than case sensitivity. For example, some older file systems defined case insensitivity based on the letters A through Z, completely ignoring other characters. Worse, they often just assumed 0x41 == 0x61, even for multi-byte character encodings (meaning two unrelated characters were considered equal). Some file systems take diacriticals into account, and some don't.

In the end, you generally have to ask the file system to look up the path and return some unique identifier (such as a combination of device identifier and node number). Then you can (usually) compare those unique identifiers. That only works for paths that already exist. Predicting whether a non-existant path will be equivalent to some other path is hard.

-Mark

···

On Aug 14, 2007, at 11:44 PM, nikolai.weibull@gmail.com wrote:

So, should Pathname#== respect the platforms case insensitivity, for
example, on Windows and on Mac OS?

23

Hi --

* <dblack@rubypal.com> (16:48) schrieb:

That is true for Array#delete. delete is always destructive, there is no
need to flag that.

And push, pop, <<, concat, replace, clear...

Which all have to be modifying. With the exception of concat. (The Unix
cat command isn't modifying.)

It should simply be clear from the name[0] if a method is destructive.
Often you need the ! for that, in some cases it's obvious without the !.

I guess I take my cue from the Ruby core/standard language, where
there's no use of !, as far as I know, except to distinguish a
"dangerous" method from its non-dangerous partner.

That's because of the completeness of the library. Whenever there can be
a non-modifying partner, there is one.

! does not mean modifying; it means "dangerous".

When you just define a modifying method, is not right to name it without
a ! just because you choose not to define a non-modifying version.

I would never add a ! to a method name solely because it changes the
receiver. That's a re-invention of what ! is for.

What if some other developer wants to add the non-modifying version?
He would have to rename your version.

I think that's a solution in search of a problem. Just name your
methods clearly, without !. Then, if you (or someone else) want to add
a "dangerous" version, you can write the ! method.

Also -- once again -- ! does not mean that the receiver is changed. It
means "dangerous"; it's a warning to the programmer that the method is
going to do something that the non-! version doesn't do, and that
might involve the unexpected.

! is not a general-purpose receiver-modifying flag, and I would very
strongly discourage its adaptation to that use. It's not necessary,
and it dilutes the original purpose of !.

David

···

On Wed, 15 Aug 2007, Simon Krahnke wrote:

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

24

Just thought that I'd mention the usual example of the difference is exit
vs. exit! Neither is a "modifying" version of each other.

···

On 8/15/07, dblack@rubypal.com <dblack@rubypal.com> wrote:

Hi --

On Wed, 15 Aug 2007, Simon Krahnke wrote:

> * <dblack@rubypal.com> (16:48) schrieb:
>
>>> That is true for Array#delete. delete is always destructive, there is
no
>>> need to flag that.
>>
>> And push, pop, <<, concat, replace, clear...
>
> Which all have to be modifying. With the exception of concat. (The Unix
> cat command isn't modifying.)
>
>>> It should simply be clear from the name[0] if a method is destructive.
>>> Often you need the ! for that, in some cases it's obvious without the
!.
>>
>> I guess I take my cue from the Ruby core/standard language, where
>> there's no use of !, as far as I know, except to distinguish a
>> "dangerous" method from its non-dangerous partner.
>
> That's because of the completeness of the library. Whenever there can be
> a non-modifying partner, there is one.

! does not mean modifying; it means "dangerous".

25

* <dblack@rubypal.com> (13:48) schrieb:

That's because of the completeness of the library. Whenever there can be
a non-modifying partner, there is one.

! does not mean modifying; it means "dangerous".

Most methods flagged with a ! are dangerous because they modify their
receiver.

When you just define a modifying method, is not right to name it without
a ! just because you choose not to define a non-modifying version.

I would never add a ! to a method name solely because it changes the
receiver. That's a re-invention of what ! is for.

No, you add it because someone might else assume it is a non-modifying
method, that is what makes it dangerous.

Array#pop is modifying but not dangerous, because everyone expects it to
be modifying.

What if some other developer wants to add the non-modifying version?
He would have to rename your version.

I think that's a solution in search of a problem.

No, that's a problem.

Just name your methods clearly, without !. Then, if you (or someone
else) want to add a "dangerous" version, you can write the ! method.

You are the one who's proposing that something isn't dangerous because
there currently isn't a less dangerous version.

mfg, simon .... l

26

Hi --

* <dblack@rubypal.com> (13:48) schrieb:

That's because of the completeness of the library. Whenever there can be
a non-modifying partner, there is one.

! does not mean modifying; it means "dangerous".

Most methods flagged with a ! are dangerous because they modify their
receiver.

Many of them are, but there's no cause-and-effect between modifying
and !. If there were, there would be !'s on all modifying methods. I
think we should really put that to rest; the convention just doesn't
work that way, and never has.

When you just define a modifying method, is not right to name it without
a ! just because you choose not to define a non-modifying version.

I would never add a ! to a method name solely because it changes the
receiver. That's a re-invention of what ! is for.

No, you add it because someone might else assume it is a non-modifying
method, that is what makes it dangerous.

Array#pop is modifying but not dangerous, because everyone expects it to
be modifying.

If the name doesn't connote destructiveness, then you should change
the name. For example, I would not use the name "last" instead of
"pop", because "last" does not connote destructiveness.

But I also wouldn't use "last!". Just adding a ! does not change a bad
name for a destructive method into a good name. It just adds a !.

What if some other developer wants to add the non-modifying version?
He would have to rename your version.

I think that's a solution in search of a problem.

No, that's a problem.

Not really. If I have a "pop" method, and someone wants to write
"last" (i.e., return the last element but not destructively), they
don't have to write "pop!-minus-!". They should choose the best name,
which may have nothing to do with the name I gave the destructive
method.

In other words, m/m! is not the only possible ratio between methods.
There's also m/n, which can be just as close as m/m!. pop/last is an
example; so is concat/+ (also for arrays).

Just name your methods clearly, without !. Then, if you (or someone
else) want to add a "dangerous" version, you can write the ! method.

You are the one who's proposing that something isn't dangerous because
there currently isn't a less dangerous version.

I don't think I can quite follow all the convolutions we're getting
into :slight_smile: I've posted something about the ! on my blog, if anyone's
interested:

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

David

···

On Thu, 16 Aug 2007, Simon Krahnke wrote:

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

27

Instead of modifying anything, #exit! doesn't clean up after itself (run at_exit handlers, attempt to run finalizers, raise SystemExit, close file descriptors). All of these things may be dangerous.

It is #exit that does the modifying of things.

···

On Aug 15, 2007, at 16:03, Logan Capaldo wrote:

On 8/15/07, dblack@rubypal.com <dblack@rubypal.com> wrote:

On Wed, 15 Aug 2007, Simon Krahnke wrote:

* <dblack@rubypal.com> (16:48) schrieb:

I guess I take my cue from the Ruby core/standard language, where
there's no use of !, as far as I know, except to distinguish a
"dangerous" method from its non-dangerous partner.

That's because of the completeness of the library. Whenever there can be
a non-modifying partner, there is one.

! does not mean modifying; it means "dangerous".

Just thought that I'd mention the usual example of the difference is exit
vs. exit! Neither is a "modifying" version of each other.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

28

* <dblack@rubypal.com> (04:19) schrieb:

Most methods flagged with a ! are dangerous because they modify their
receiver.

Many of them are, but there's no cause-and-effect between modifying
and !.

You are hitting a strawman.

Array#pop is modifying but not dangerous, because everyone expects it to
be modifying.

If the name doesn't connote destructiveness, then you should change
the name.

Obviously the many examples of pairs with and without ! don't follow
that guideline.

What if some other developer wants to add the non-modifying version?
He would have to rename your version.

I think that's a solution in search of a problem.

No, that's a problem.

Not really. If I have a "pop" method,

We have an "apply" method.

In other words, m/m! is not the only possible ratio between methods.

Who said it was?

There's also m/n, which can be just as close as m/m!. pop/last is an
example; so is concat/+ (also for arrays).

And there is m/m!. If you write m!, name it m!, not m.

I don't think I can quite follow all the convolutions we're getting
into :slight_smile: I've posted something about the ! on my blog, if anyone's
interested:

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

You write "create the traditional pair of methods", that's right. But now
I'm too lazy to write the simple non-modifying wrapper. That's not a good
reason to omit the !.

BTW: Is there any reason you don't mention your whole name in your posts?

mfg, simon .... someone wrote a blog because of my posts

29

Hi --

···

On Fri, 17 Aug 2007, Simon Krahnke wrote:

BTW: Is there any reason you don't mention your whole name in your posts?

It's all there, just spread out between the email address and the
sign-off :slight_smile: It's possible that I used to have it in my .sig; I can't
remember.

David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)