40 ms·

Clickable link for the doc: http://phzbox.com/moka/index.html http://phzbox.com/moka/index.html Moka is still in an alpha stage; but that being said, I'd love

by phzbOx 15y ago

Clickable link for the doc: http://phzbox.com/moka/index.html http://phzbox.com/moka/index.html Moka is still in an alpha stage; but that being said, I'd love to hear some feedback. Feel free to browse the code, it should be pretty straightforward to any python dev.

andrewcooke 15y ago
two small suggestions: change .saving() to .mutable() and .rem() to .remove() (or filter(), reversing the semantics, since that is already in python) (every other method is a full word). also, maybe .mutable() would be better as a flag in the constructor. it makes no sense to use it in a chain (in fact, that could be confusing) and is the kind of thing you should probably fix on construction rather than changing later. ps. it's not clear to me that this is better than list comprehensions, which already do much of what you have.
- phzbOx 15y ago
  Thanks for the feedback; I agree with you. Here's the reasoning behind these odds choice.. List is-a list, and Dict is-a dict.. and thus, I'd like to make it possible to safely pass these objects to already existing code. If I rename .rem to .remove, I'd break that. The reason for the chaining saving() is because it's useful to be able to toggle it. For instance: self.x = Moka.List(range(1,10)).mutable() return (self.x.map(lambda x: x*2) .immutable() .keep(gt=5)) So, basically, you change self.x with the map, but don't necessarily want to change it with the keep(). (I'm not saying it is the right thing, just why it's done that way.)
  - inportb 15y ago
    What if your mutation functions accepted a flag that set the saving behavior, and you used a sensible default?
DanielRibeiro 15y ago
A good source of inspiration: Ruby's Enumerable[1] and Scala's Iterable[2]. Toguether, they have one of the most complete functional collection methods library. [1] http://ruby-doc.org/core-1.9.3/Enumerable.html http://ruby-doc.org/core-1.9.3/Enumerable.html [2] http://www.scala-lang.org/api/current/scala/collection/immutable/Iterable.html http://www.scala-lang.org/api/current/scala/collection/immut...
tef____ 15y ago
You've invented your own incompatible dialect of python. You've broken composition, objects and the general design choices of python. 1. You break Composition Your magic flag within a list changes all the semantics of the methods between immutable and mutable lists. > x = List([1,2,3]).saving() So now, if you're passed a list you have no idea if the operations you do will mutate the list. This breaks composition entirely. You can't pass a mutable list into a function built for immutable lists without destroying things. 2. You break objects Picking another example, this breaks duck typing and inheritance and polymorphism. >def user_logged(users): > return List(users).all(User.is_logged) this does not have the same semantics as: > def user_logged(users): > return all(user.is_logged() for user) Because the method lookup is done per instance, rather than assuming everything is the same class. 3. You're writing jquery in python Python chose not to demand that all iterables implement a series of operators, but provides them as functions within a module. The rationale is that it is easier to add new functions within itertools, and there is far less to do to correctly implement the iterator protocol You can see this in the "".join(foo) operator too. Instead of demanding all iterables support join, string takes an iterable as argument. Making readable and maintainable python comes from using the existing idioms within the language and used within the community. Your proposed solution isn't readable, and it isn't pythonic.
- phzbOx 15y ago
  Thanks for the feedback, these are interesting points. I'd like to clarify a couple of things about your #2 and #3. def user_logged(users): > return List(users).all(User.is_logged) # If you want per instance: def user_logged(users): > return List(users).all(lambda x: x.is_logged()) And, about the "".join; you are right. However, Moka's construct allow you to use whatever you want, i.e.: moka.List(['a', 'b']).do(string.join, '').last_value Or, you can still use: ''.join(moka.List(['a', 'b'])) However, about the #1, I have to agree. I've added the saving() recently and had a bad taste about it. The right way to do it might be to make it mutable by default and only toggle it off in certain circumstances. Please note that everything done by the community is still perfectly usable; in fact, it's even easier to use useful high-level functions. I.e. map(str, range(1,10)) or List(range(1,10)).map(str); is syntactically different but does the same job.
rhizome31 15y ago
You should really give Ruby a try.

by phzbOx 15y ago

andrewcooke 15y ago

two small suggestions: change .saving() to .mutable() and .rem() to .remove() (or filter(), reversing the semantics, since that is already in python) (every other method is a full word). also, maybe .mutable() would be better as a flag in the constructor. it makes no sense to use it in a chain (in fact, that could be confusing) and is the kind of thing you should probably fix on construction rather than changing later. ps. it's not clear to me that this is better than list comprehensions, which already do much of what you have.

phzbOx 15y ago
Thanks for the feedback; I agree with you. Here's the reasoning behind these odds choice.. List is-a list, and Dict is-a dict.. and thus, I'd like to make it possible to safely pass these objects to already existing code. If I rename .rem to .remove, I'd break that. The reason for the chaining saving() is because it's useful to be able to toggle it. For instance: self.x = Moka.List(range(1,10)).mutable() return (self.x.map(lambda x: x*2) .immutable() .keep(gt=5)) So, basically, you change self.x with the map, but don't necessarily want to change it with the keep(). (I'm not saying it is the right thing, just why it's done that way.)
- inportb 15y ago
  What if your mutation functions accepted a flag that set the saving behavior, and you used a sensible default?

DanielRibeiro 15y ago

A good source of inspiration: Ruby's Enumerable[1] and Scala's Iterable[2]. Toguether, they have one of the most complete functional collection methods library. [1] http://ruby-doc.org/core-1.9.3/Enumerable.html http://ruby-doc.org/core-1.9.3/Enumerable.html [2] http://www.scala-lang.org/api/current/scala/collection/immutable/Iterable.html http://www.scala-lang.org/api/current/scala/collection/immut...

tef____ 15y ago

You've invented your own incompatible dialect of python. You've broken composition, objects and the general design choices of python. 1. You break Composition Your magic flag within a list changes all the semantics of the methods between immutable and mutable lists. > x = List([1,2,3]).saving() So now, if you're passed a list you have no idea if the operations you do will mutate the list. This breaks composition entirely. You can't pass a mutable list into a function built for immutable lists without destroying things. 2. You break objects Picking another example, this breaks duck typing and inheritance and polymorphism. >def user_logged(users): > return List(users).all(User.is_logged) this does not have the same semantics as: > def user_logged(users): > return all(user.is_logged() for user) Because the method lookup is done per instance, rather than assuming everything is the same class. 3. You're writing jquery in python Python chose not to demand that all iterables implement a series of operators, but provides them as functions within a module. The rationale is that it is easier to add new functions within itertools, and there is far less to do to correctly implement the iterator protocol You can see this in the "".join(foo) operator too. Instead of demanding all iterables support join, string takes an iterable as argument. Making readable and maintainable python comes from using the existing idioms within the language and used within the community. Your proposed solution isn't readable, and it isn't pythonic.

phzbOx 15y ago
Thanks for the feedback, these are interesting points. I'd like to clarify a couple of things about your #2 and #3. def user_logged(users): > return List(users).all(User.is_logged) # If you want per instance: def user_logged(users): > return List(users).all(lambda x: x.is_logged()) And, about the "".join; you are right. However, Moka's construct allow you to use whatever you want, i.e.: moka.List(['a', 'b']).do(string.join, '').last_value Or, you can still use: ''.join(moka.List(['a', 'b'])) However, about the #1, I have to agree. I've added the saving() recently and had a bad taste about it. The right way to do it might be to make it mutable by default and only toggle it off in certain circumstances. Please note that everything done by the community is still perfectly usable; in fact, it's even easier to use useful high-level functions. I.e. map(str, range(1,10)) or List(range(1,10)).map(str); is syntactically different but does the same job.

rhizome31 15y ago

You should really give Ruby a try.