Hi
I miss 3.member_of(1..5)
Shouldn't that be included?
Where to post such things?
Perhaps someone "responsible" reading this mail?
cheers Berg
Where is member_of defined?
Is this a method you added?
You can do (1..5).include?(3)
James
···
On Wed, 10 Aug 2016 at 10:00 A Berger <aberger7890@gmail.com> wrote:
Hi
I miss 3.member_of(1..5)
Shouldn't that be included?
Where to post such things?
Perhaps someone "responsible" reading this mail?cheers Berg
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Hi,
I think you want something like :
class Fixnum
def member_of?(rg)
rg.include? self
end
end
Is that right ?
Guillaume
Where is member_of defined?
Is this a method you added?
You can do (1..5).include?(3)
James
Hi
I miss 3.member_of(1..5)
Shouldn't that be included?
Where to post such things?
Perhaps someone "responsible" reading this mail?
cheers Berg
Unsubscribe: <mailto:[ruby-talk-request@ruby-lang.org](mailto:ruby-talk-
request@ruby-lang.org)?subject=unsubscribe>
<<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>>
···
On août 10 2016, at 12:01 pm, James Doyley <jdoyley@gmail.com> wrote:
On Wed, 10 Aug 2016 at 10:00 A Berger <[aberger7890@gmail.com](mailto:aberger7890@gmail.com)> wrote:
Yes, but within class Object
(or is another one better?)
Cheers Berg
I miss 3.member_of(1..5)
you can include rails (active_support)
3.in? 1..5
=> true
best regards,
--botp
···
On Wed, Aug 10, 2016 at 5:00 PM, A Berger <aberger7890@gmail.com> wrote:
The problem I have:
I want to stay "conform" - so dont use things, which arent available as
default =>
implication:
This method should be in the kernel!
Do most agree? Does anything speak against it?
(ok there are bigger/more important things, it's not one of the most
important functions)
Thx Berg
Considering that active_support is a really big dependency
and also how easy it is to achieve the same with #include?,
IMO it's really not worth it.
(A good example of how problematic it can be to pull in a
more or less unnecessary dependency was the NPM desaster
for JavaScript earlier this year; in that case everyone
relied on the "left-pad" module -- only a handful of lines
of code -- that was at some time unpublished, which broke
many apps.)
Regards,
Marcus
···
Am 10.08.2016 um 19:06 schrieb botp:
On Wed, Aug 10, 2016 at 5:00 PM, A Berger <aberger7890@gmail.com> wrote:
I miss 3.member_of(1..5)
you can include rails (active_support)
3.in? 1..5
=> true
--
GitHub: stomar (Marcus Stollsteimer) · GitHub
PGP: 0x6B3A101A
Short answers: No. Yes.
Simply use
(1..5).include? 3
Regards,
Marcus
···
Am 10.08.2016 um 14:56 schrieb A Berger:
This method should be in the kernel!
Do most agree? Does anything speak against it?
--
GitHub: https://github.com/stomar/
PGP: 0x6B3A101A
As others have said, no, I don't think it's generally useful. A method
defined on an object should in some way represent an attribute of that
object. Membership of a group isn't an attribute of the object, it's an
attribute of the group, which is why #include? is defined on enumerables
(i.e. collections.)
However sometimes it's useful to produce a value, and then pass that value
to another object. If you write this code:
foo.bar(1,2).baz(qux).frebble
... and then you want to see if that final value is part of some array, you
either have to wrap the whole chain of calls up as a parameter:
the_array.include? foo.bar(1,2).baz(qux).frebble
...which can cause some dissonance (because the_array is the first thing
you see on the line, but it's the *value *you care about); or you can store
it in a variable:
temporary_variable = foo.bar(1,2).baz(qux).frebble
the_array.include? temporary_variable
...because everyone is really good at naming temporary variables.
You can use the #tap method to get around this, using a bit of clever
voodoo:
foo.bar(1,2).baz(qux).frebble.tap{|x| break the_array.include?(x) }
...which is used just enough to be a sort of idiom, but will definitely
confuse people the first time they see it. For a while now Ruby has
included the method #itself (which just returns the object it's called on),
there are several open proposals[1] to allow a block to be passed to #itself,
which would return the value of the block. Thus you'd have:
foo.bar(1,2).baz(qux).frebble.itself{|x| the_array.include? x }
Then you'd be able to write your expression left-to-right, the way you
think of it; but right now that can only be done using a gem, or by
modifying the core classes yourself[2].
Cheers
[1]: https://bugs.ruby-lang.org/issues/10883
[2]: https://github.com/phluid61/mug/blob/master/lib/mug/self.rb
···
On 10 August 2016 at 22:56, A Berger <aberger7890@gmail.com> wrote:
The problem I have:
I want to stay "conform" - so dont use things, which arent available as
default =>
implication:
This method should be in the kernel!
Do most agree? Does anything speak against it?
(ok there are bigger/more important things, it's not one of the most
important functions)Thx Berg
--
Matthew Kerwin
http://matthew.kerwin.net.au/
obj for obj sake, ie then.
cmon, matt, ruby is not that stiff : )
there are many ruby methods that act as basic functions: print, puts,
is_a?, is_defined?.. etc...
not to mention the other perlistic methods acquired by ruby : ) )
kind regards
--botp
···
On Thu, Aug 11, 2016 at 5:59 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
As others have said, no, I don't think it's generally useful. A method
defined on an object should in some way represent an attribute of that
object. Membership of a group isn't an attribute of the object, it's an
attribute of the group, which is why #include? is defined on enumerables
(i.e. collections.)
> As others have said, no, I don't think it's generally useful. A method
> defined on an object should in some way represent an attribute of that
> object. Membership of a group isn't an attribute of the object, it's an
> attribute of the group, which is why #include? is defined on enumerables
> (i.e. collections.)obj for obj sake, ie then.
cmon, matt, ruby is not that stiff : )
there are many ruby methods that act as basic functions: print, puts,
is_a?, is_defined?.. etc...
not to mention the other perlistic methods acquired by ruby : ) )
Honestly? From my point of view, one of the nicer things about Ruby is that it *does* stick to that rule pretty closely.
None of the examples you give are methods that belong in the individual objects -- in my opinion.
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
> As others have said, no, I don't think it's generally useful. A method
> defined on an object should in some way represent an attribute of that
> object. Membership of a group isn't an attribute of the object, it's an
> attribute of the group, which is why #include? is defined on enumerables
> (i.e. collections.)obj for obj sake, ie then.
Sorry, I don't know what you're saying here.
cmon, matt, ruby is not that stiff : )
there are many ruby methods that act as basic functions:
Well, yes, if you're talking about functions vs properties/attributes
that's true. I thought we were talking about defining a value-returning
*method* *on an object* that doesn't represent an attribute or property of
that object.
print, puts,
Those are very useful convenience functions, it would be silly to argue
against them. (Although if you like a more pure OO flavour in your code,
similar methods are also defined on `IO`, so you can call `STDOUT.print` or
`$stderr.puts` etc.)
is_a?,
That's actually one of the attributes I was referring to. ` foo.is_a? Bar`
is asking whether foo has Bar as an ancestor (basically.) Since *all* objects
have 'ancestry', it makes sense to make it queryable.
is_defined?.. etc...
That's a language function. The only other way to get that information
would be to expose the actual Ruby AST and/or symbol tables in the
language. Which is crazy. Again, I've no problem with *functions*.
not to mention the other perlistic methods acquired by ruby : ) )
In my experience, perlistic *methods* all pass the receiver as the first
parameter. The basic pattern is:
package Foo;
sub new {
my $class = shift;
return bless {foo => 1}, $class;
}
sub foo {
my $self = shift;
return $self->{foo};
}
# - - -
my $obj = Foo->new();
$obj->foo(); # returns 1
i.e. the receiver/object contains attributes, and the method accesses an
attribute of the receiver. Not all perl subroutines are *methods*, of
course, but those that are tend to follow the same pattern.
kind regards
--botp
Cheers
···
On 12 August 2016 at 00:05, botp <botpena@gmail.com> wrote:
On Thu, Aug 11, 2016 at 5:59 AM, Matthew Kerwin <matthew@kerwin.net.au> > wrote:
--
Matthew Kerwin
http://matthew.kerwin.net.au/