multimethod, record, type, and protocol pitfalls?

[Daniel Higginbotham]

What's difficult when it comes to understanding multimethods, records, types, and protocols? I'm writing a chapter on multimethods, records, types, and protocols for the book Clojure for the Brave and True, and I'd love to hear about what kinds of pitfalls I should be sure to cover :)

Thanks!
Daniel

[Ashton Kemerling]

The way defmulti handles argument matching. I could be incorrect, but if I recall I was forced to use namespaced keywords for matching, and I couldn't use & args like I wanted to. 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Haney]

I recently ran into the & args issue as well. I'm sure I read about when I was learning clojure, but it's easy to forget.

[Sven Richter]

Hi Daniel,

When running through tutorials and blog posts it did not occur to me that the functions of a defprotocol are namespaced to where they are defined. Meaning, calling these functions I have to use their original namespace.
It is obvious when one reads the official documentation, but one does not always do this first, so that wsa one pitfall I ran into.

Best Regards,
Sven

[Gary Verhaegen]

As recently mentioned on another thread, this also means that you cannot have two different protocols with the same method names in the same namespace. This may be surprising, especially from an OO background, where it is very natural to have two types with the same operations.

--

[Daniel Higginbotham]

These responses are all super helpful, thank you! I'd love to hear more pitfalls/pain points if anyone else wants to share.

Thanks!

Daniel

On Monday, October 27, 2014 6:59:43 AM UTC-4, Gary Verhaegen wrote:

As recently mentioned on another thread, this also means that you cannot have two different protocols with the same method names in the same namespace. This may be surprising, especially from an OO background, where it is very natural to have two types with the same operations.

On Monday, 27 October 2014, Sven Richter <sve...@googlemail.com> wrote:

Hi Daniel,

When running through tutorials and blog posts it did not occur to me that the functions of a defprotocol are namespaced to where they are defined. Meaning, calling these functions I have to use their original namespace.
It is obvious when one reads the official documentation, but one does not always do this first, so that wsa one pitfall I ran into.

Best Regards,
Sven

Am Sonntag, 26. Oktober 2014 16:48:29 UTC+1 schrieb Daniel Higginbotham:

What's difficult when it comes to understanding multimethods, records, types, and protocols? I'm writing a chapter on multimethods, records, types, and protocols for the book Clojure for the Brave and True, and I'd love to hear about what kinds of pitfalls I should be sure to cover :)

Thanks!
Daniel

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[larry google groups]

The differences between OOP and multimethods should be stressed. 

I just wrote about this on my blog, and those who mostly worked with OOP kept wondering, how do you get inheritance of functionality? Actually, they did not ask this clearly, so it took me awhile to understand their question, and then explain that you can simulate something like the inheritance of an interface, but not functionality. I also said that keyword inheritance and polymorphism could be combined to deliver a simulation of OOP style inheritance of functionality. But folks coming from the OOP world tend to hear the word "inheritance" and think there is a way to inherit functionality, and that is not really true. 

It's sort of an advanced subject, but you can store keywords (belonging to some hierarchy) in the :tags metadata on the var and then match against that with multimethds, and simulate something close to the OOP style, but that leads into the question of why it might be a bad idea to try to imitate every OOP idea in Clojure. 

There are some questions on Stackoverflow where people ask "How do I get inheritance of functionality in Clojure?" 

[Gary Verhaegen]

It has not been a pain point for me so far, but there is one more thing that may be somewhat surprising: multimethods and protocols introduce non-locality into the code.

This means that, with code that uses multimethods or protocols, sometimes requiring a namespace and not using any symbol from it is not a mistake. It also means that debugging gets a lot harder.

They are both pretty good to provide extension points, but it is a tradeoff that is maybe not emphasized enough, as code locality is, for me, the biggest advantage of functional programming.

This is somewhat akin to use vs require.

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.

[Rogerio Senna]

On Mon, Oct 27, 2014 at 2:21 PM, larry google groups <lawrenc...@gmail.com> wrote:
​

The differences between OOP and multimethods should be stressed. 

I just wrote about this on my blog, and those who mostly worked with OOP kept wondering, how do you get inheritance of functionality?

​

​First of all, let me state that I'm a complete Clojure noob. Still, I thought that Clojure's multimethods were a completely valid OOP approach.

​

Q

​uoting Alan Kay:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.​

​Notice that he intentionally left "inheritance" out from that definition.

That means that the class based, C++ style that we usually call "OOP" is actually just one particular kind of OOP - so the way that JavaScript, Common-Lisp CLOS and, as I see it, Clojure multimethods do it are also valid "OOP" as well, I believe.

Am I right? Or am I missing something here?

Thanks in advance,

Rogerio.

​​

[Raoul Duke]

> Notice that he intentionally left "inheritance" out from that definition.

there are more connotations of "object oriented" than there are quills
on a porcupine.

[Rogerio Senna]

​Sure. But since Alan Kay is the guy who invented the term "object oriented", I guess his definition should be, at least, considered.

It seems that nowadays that only Java is properly "object oriented". This is far from true.

[Raoul Duke]

> Sure. But since Alan Kay is the guy who invented the term "object oriented",
> I guess his definition should be, at least, considered.
> It seems that nowadays that only Java is properly "object oriented". This is
> far from true.

i suspect you read my note as trying to pick a side.

[larry google groups]

> ​First of all, let me state that I'm a complete Clojure noob. 

> Still, I thought that Clojure's multimethods were a completely 

> valid OOP approach.
> 

​

Q

​uoting Alan Kay:

When I have made that point (about Alan Kay's vision) to certain OOP evangelists, I have been told that Alan Kay's vision of OOP is no longer relevant, or that I have misunderstood it. I do not mean to drag you into a long debate, nor do I wish to waste your time, but if you are very patient, and you have a lot of free time on your hands, you can read what I wrote (very long and badly edited) here: 

http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end

and then check out the various ways people responded on Hackers News (I feel that I was misunderstood, though I take the blame, as my essay was not as clear as it should have been): 

https://news.ycombinator.com/item?id=8420060

A dozen people wrote me private emails after I posted that blog post, and several of them asked me how to get inheritance of functionality in something like Clojure. 

I am writing a follow-up post (which I promise will be shorter and better edited than the original post) and one thing I am doing is writing examples of how you could imitate the OOP style using Haskell or Clojure (which apparently I should have done in the first post). 

--- lawrence 

[Jason Wolfe]

Not sure if this is exactly what you're looking for, but there might be some relevant info here:

https://github.com/Prismatic/eng-practices/blob/master/clojure/20130926-data-representation.md

Comments/suggestions/questions welcome.  

-Jason

[Daniel Higginbotham]

Thanks for the responses! This is very helpful.

[kovas boguta]

Heres one thing:

https://groups.google.com/forum/#!topic/clojure/ILPz4QOEod8

Requiring the namespace where you declared the type is not enough, you need to import the type separately if you want to avoid using the fully-qualified name. 

There is also a difference in this behavior between clojure and clojurescript.

On Sat, Nov 1, 2014 at 2:13 PM, Daniel Higginbotham <nonrec...@gmail.com> wrote:

Thanks for the responses! This is very helpful.

--

[kovas boguta]

Maybe the most confusing thing is which construct to use when.

I've found the following posts to be pretty helpful in sorting out the different tradeoffs:

https://github.com/Prismatic/eng-practices/blob/master/clojure/20130926-data-representation.md

http://cemerick.com/2011/07/05/flowchart-for-choosing-the-right-clojure-type-definition-form/

[Adam Krieg]

My experience with protocols is that the implementations can't be redefined, e.g changing an implementation.  So if you change one of the applied protocols, you may need to restart your REPL. YMMV.

Using records outside of their declared namespace is also really weird.  You need to both require the namespace and import the record IN THAT ORDER. If you import the Record and then require the namespace, it doesn't work, which is a nasty wart, IMO.

On Sunday, October 26, 2014 11:48:29 AM UTC-4, Daniel Higginbotham wrote:

[Gary Trakhman]

You don't need to import the record if you use the auto-gen'd factories, ->RecordName and map->RecordName.  You can and also shouldn't import the java interfaces created by protocols.  

It's possible to interactively develop this way, but you really have to know what's being eval'd and what types are invalidated to do so, and is generally not recommended.

Extend-type is easier to use interactively than inline protocol extensions (which are faster) as it's modifying dynamic globals.

--

[Adam Krieg]

You are right about the factory methods for Records.  My need to reference the records in another namespace was for type hinting.

[Justin Smith]

Helping newcomers to the language on #clojure, I often find the need to use a protocol in reference to it's namespace rather than the namespace of the datatype extending it is a counter-intuitive one for people learning the language. Similar with dispatch methods.

Speculatively, I think it has to do with a bad mental model of the primary "ownership" of the method - often the method is thought of as belonging to the datatype, where it actually belongs to the multimethod / protocol interface.

A good example of this in practice: people who think they need circular namespace dependencies or forward declaration in order for two records / types to interact often have a hard time realizing that if they code to a set of multimethods or a defprotocol and not a concrete datatype, the circularity / forward reference is usually trivial to eliminate. And more fundamentally that the "agency" doesn't belong to the record or type, it belongs to the method functions being called, and to abstract that away from a concrete datatype is precisely the point of these polymorphic constructs.

On Monday, October 27, 2014 3:59:43 AM UTC-7, Gary Verhaegen wrote:

As recently mentioned on another thread, this also means that you cannot have two different protocols with the same method names in the same namespace. This may be surprising, especially from an OO background, where it is very natural to have two types with the same operations.

On Monday, 27 October 2014, Sven Richter <sve...@googlemail.com> wrote:

Hi Daniel,

When running through tutorials and blog posts it did not occur to me that the functions of a defprotocol are namespaced to where they are defined. Meaning, calling these functions I have to use their original namespace.
It is obvious when one reads the official documentation, but one does not always do this first, so that wsa one pitfall I ran into.

Best Regards,
Sven

Am Sonntag, 26. Oktober 2014 16:48:29 UTC+1 schrieb Daniel Higginbotham:

What's difficult when it comes to understanding multimethods, records, types, and protocols? I'm writing a chapter on multimethods, records, types, and protocols for the book Clojure for the Brave and True, and I'd love to hear about what kinds of pitfalls I should be sure to cover :)

Thanks!
Daniel

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.