methods with and without !

[Jani Monoses]

Hello

what is the criterion for methods to have a ! terminated variant in the
standard ruby APIs?
For instance in String strip has a receiver-modifying counterpart but
ljust does not.
Is it that the result fits in the same memory? (strip returns a string
at most as long as the original while just can return a much longer one)

thanks
Jani

 

[Robert Klemme]

Hello

what is the criterion for methods to have a ! terminated variant in the
standard ruby APIs?
For instance in String strip has a receiver-modifying counterpart but
ljust does not.
Is it that the result fits in the same memory? (strip returns a string
at most as long as the original while just can return a much longer one)

Normally the rule is that the method modifies the current instance as
opposed to the creation of a new instance (e.g. String#gsub! and
String#gsub). But that convention is not followed consistently in the std
lib. I guess the explanatory text contains "historic reasons" somewhere.
:-}

Kind regards

robert

 

[Jani Monoses]

Normally the rule is that the method modifies the current instance as
opposed to the creation of a new instance (e.g. String#gsub! and
String#gsub). But that convention is not followed consistently in the std
lib. I guess the explanatory text contains "historic reasons" somewhere.
:-}

maybe it was my bad wording I know that ! versions modify in place
(scheme heritage?)
I was asking which methods should have a ! variant along the regular one.
We have sub and sub!, strip and strip! but no String#just! only String#just
Does in-place imply then that no memory allocation will be done and the
result must fit in the calling object?

Jani



Jani

 

[David A. Black]

Hi --

maybe it was my bad wording I know that ! versions modify in place
(scheme heritage?)
I was asking which methods should have a ! variant along the regular one.
We have sub and sub!, strip and strip! but no String#just! only String#just
Does in-place imply then that no memory allocation will be done and the
result must fit in the calling object?

No:

"a".sub!(/a/, "aaaaaaaaaaaaaaaaaaaaaaaaaa")


David

 

[Bill Guindon]

maybe it was my bad wording I know that ! versions modify in place
(scheme heritage?)
I was asking which methods should have a ! variant along the regular one.
We have sub and sub!, strip and strip! but no String#just! only String#just

It does seem a bit arbitrary.

Personally, I'd like 'modify in place' versions of every method
possible, but some of them would cause type conversions (ie: pack!,
split!, hex!), which might be a bit 'surprising' to some people, so I
could understand not adding those (but I would still want them).

I think the lack of modify methods like ljust!, center!, crypt!,
dump!, etc (where a String is returned), was really just a question of
language style.

 

[Robert Klemme]

String#just

It does seem a bit arbitrary.

Personally, I'd like 'modify in place' versions of every method
possible, but some of them would cause type conversions (ie: pack!,
split!, hex!), which might be a bit 'surprising' to some people, so I
could understand not adding those (but I would still want them).

You can't have them, because Ruby instances can't change their class. But
you can always do foo = foo.gsub(/x/, 'u'), i.e., reassign the var to the
result of the conversion.

Regards

robert

 

[Aredridel]

Normally the rule is that the method modifies the current instance as

opposed to the creation of a new instance (e.g. String#gsub! and
String#gsub). But that convention is not followed consistently in the std
lib. I guess the explanatory text contains "historic reasons" somewhere.
:-}

More accurately, ! just means "be careful" -- exit! (no cleanup),
sub! (modifies receiver) ... that sort of thing.

 

[Hal Fulton]

maybe it was my bad wording I know that ! versions modify in place
(scheme heritage?)
I was asking which methods should have a ! variant along the regular one.
We have sub and sub!, strip and strip! but no String#just! only String#just
Does in-place imply then that no memory allocation will be done and the
result must fit in the calling object?

Most but not all bang methods modify the receiver in-place. But that is
not the "meaning" of the bang.

The implication of the bang is that the method is more dangerous or more of
a special case. The exit! method, for example, exits without running the
exit handlers.


Hal