Anton,
These are all very good questions. I'm going to try to
write up an essay about these topics suitable for
posting on my blog, since there's so much to say.
The use of packages that I have been advocating
here is not used a lot in practice in Common Lisp,
but the more I think about it, the
Daniel, I think I understand the issue better now. Not that your idea - how base class provides implementation for reuseby subclasses and using packages to specify this protocol - was impossibleto understand from your first mail. I see that my doubts and the form of my previous email are caused by
Anton,
Thank you very much for your mail. It prompted me
to explain what I'm thinking of in a much more
clear (I hope!!) way. Here we go:
Anton Vodonosov wrote:
What is the difference
for modularity in case of subclassing, from other cases were we apply modularity?
I can't find the differen
Anton,
Thank you very much for your mail. It prompted me to explain what I'm
thinking of in a much more clear (I hope!!) way. Here we go:
Anton Vodonosov wrote:
> What is the difference
> for modularity in case of subclassing, from other cases were we apply
modularity?
> I can't find the d
On Dec 7, 2010, at 11:10 PM, Matthew D. Swank wrote:
> On 12/07/2010 09:19 PM, Faré wrote:
>> A better question might be
>> how do you enforce disjointness of some mixins. I suppose a
>> heavy-handed use of MOP magic could do it, but oh well.
> Q: Doctor, it hurts when I do this.
> A: Well, don't
On 12/07/2010 09:19 PM, Faré wrote:
> A better question might be
> how do you enforce disjointness of some mixins. I suppose a
> heavy-handed use of MOP magic could do it, but oh well.
Q: Doctor, it hurts when I do this.
A: Well, don't do that.
In the examples I looked at that inspired me to use I
On 7 December 2010 14:00, Pascal Costanza wrote:
> On 1 Dec 2010, at 18:16, Faré wrote:
> The term 'mixins' sets of my alarm bells. ;) But first a question, to better
> understand what you mean here: How do you reconcile the notion of mixins with
> multiple dispatch?
>
I don't know that there's
On 1 Dec 2010, at 18:16, Faré wrote:
> On 1 December 2010 10:25, Daniel Weinreb wrote:
>> First, a common base class can provide implementations of some of the
>> generic functions all by itself. My favorite simple example is an
>> "output stream" protocol, that has a write-character operation
On 1 Dec 2010, at 21:16, Daniel Weinreb wrote:
> I have always liked the idea of having protocols
> say more than just "these are the functions
> and these are the arguments, which are optional,
> ane maybe what their types are. I'd love it
> if there were a way to say "in order to fulfill
> thi
On 1 Dec 2010, at 16:25, Daniel Weinreb wrote:
> I call the set of defgenerics (plus the factory functions) the
> "protocol". The word "type" is sort of right but carries a lot of
> connotations and freight that I'd rather avoid.
In the Haskell community, these beasts are called 'type classes'.
On Wed, Dec 1, 2010 at 8:29 PM, Daniel Herring wrote:
> On Wed, 1 Dec 2010, Daniel Weinreb wrote:
>
>> Smalltalk didn't even try. CLOS, I believe, does not try and there is
>> not an idiomatic way to do it. The only language I know that makes a
>> good stab in this direction is C++, which has "p
I think the idea to use packages to specify module protocol
(interface, contract) is right.
And also I think this is better than to have a separate
public/protected/private
language feature for classes.
What would be the motivation for a separate language feature? What is the
difference
for
On 12/01/2010 03:11 PM, Faré wrote:
>> I have always liked the idea of having protocols
>> say more than just "these are the functions
>> and these are the arguments, which are optional,
>> ane maybe what their types are.
>>
> You can have that in Lisp to a point with Interface-Passing Style:
>
On Wed, 1 Dec 2010, Daniel Weinreb wrote:
> Smalltalk didn't even try. CLOS, I believe, does not try and there is
> not an idiomatic way to do it. The only language I know that makes a
> good stab in this direction is C++, which has "public", "protected",
> and "private". Whatever else you say
> I have always liked the idea of having protocols
> say more than just "these are the functions
> and these are the arguments, which are optional,
> ane maybe what their types are.
>
You can have that in Lisp to a point with Interface-Passing Style:
http://fare.livejournal.com/155094.html
Faré wrote:
On 1 December 2010 10:25, Daniel Weinreb wrote:
Here is a way that CL sucks badly: protocols are not first-class entities.
To modify a protocol is something done to the source code *outside* of the
Lisp world. It cannot be done programmatically.
Adherence to the protocol cannot
On 1 December 2010 10:25, Daniel Weinreb wrote:
> I call the set of defgenerics (plus the factory functions) the
> "protocol". The word "type" is sort of right but carries a lot of
> connotations and freight that I'd rather avoid.
>
Here is a way that CL sucks badly: protocols are not first-class
(This is a new topic.)
Many times, people have presented a major problem with object-oriented
programming as it is often/idiomatically used. The good thing is that
OOP, when done right (in Lisp, that means, among other things, always
using defgeneric explicitly), provides a great abstarct interfa
18 matches
Mail list logo
