"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bvjrpf$10ne$1@digitaldaemon.com...
> Vathix wrote:
> | This seems interesting from heron:
> |
> |
> ||| Operator
> | The "|>" or pipe operator works as both an input and an output
> | operator allowing data to be recieved from any source that implements
> | the IWritePipe interface and to any source that implements the
> | IReadPipe interface.
>
> While I can see the motivation for an operator like that, I truly fail to see what's so different about it from the ordinary assignment operator.

x := y; // maps to x.Assign(y);
y |> x; // maps to an untyped buffered transfer of bytes.

The semantics are very different. For instance :

matrix |> text_file; // This makes sense
text_file := matrix; // this doesn't make sense

So it would be pointless to just lump these together as both assignment.

-- 
Christopher Diggins
yet another language designer
http://www.heron-language.com

"christopher diggins" <cdiggins@users.sourceforge.net> wrote in message news:bvk72b$1kv9$1@digitaldaemon.com...
> > It's an interesting read. I'd like to know what language the author
*does*
> > use, and why.
> Thanks for the compliment on the article. As a couple of other have
pointed
> out, I am working on my own language Heron. Here is what particularly motivates me about Heron :
>
> - no class inheritance, polymorphism based entirely on interfaces and
> delegation of implementation
> - memory protection without garbage collection
> - clear delineation between referencing variables and assigning values
> - inexpensive templates (no code bloat)
> - modular organization of code
> - objects are value types that can be referenced if desired
> - operator overloading
> - no special array type, array is just a class defined in the standard
> library as is every other primitive
> - restricted run time type information through variants
>
> I hope this helps answer your question Walter.

Yes, it does. Thanks! And good luck with your efforts.

In article <bvjjso$j6h$1@digitaldaemon.com>, Walter says...
>
>
>"Mark T" <Mark_member@pathlink.com> wrote in message news:bvj7r4$30rl$1@digitaldaemon.com...
>> http://www.heron-language.com/c-sharp-critique.html
>
>It's an interesting read. I'd like to know what language the author *does* use, and why.
>
>

I'm surprised he uses English... rather than Esperanto (sp).

The Lone Haranguer wrote:
| I'm surprised he uses English... rather than Esperanto (sp).

If you like Esperanto, you'll really like Ido:  http://www.idolinguo.com/

In article <bvmje8$2iob$1@digitaldaemon.com>, Sean L. Palmer says...
>
>The Lone Haranguer wrote:
>| I'm surprised he uses English... rather than Esperanto (sp).
>
>If you like Esperanto, you'll really like Ido:  http://www.idolinguo.com/

Oh you're evil... Because of you, I just spent the last several hours learning Ido... and I have a lot of work to do...

*ploras* Me juas ta linguo...

>> Unfortunately D doesn't allow you to overload assignment.
>
>I have a strong negative view of the value of overloading assignment. By not overloading it, the semantics of it are reliable and repeatable. (For example, does it do a deep, shallow, or reference copy?)
>
Right, you can never no in D.

class Foo (T)
{
T data;
void method (T value)
{
data = value;  // what happens?
}
}

If T is a class-Type you have a reference copy, if it's not you have a shallow
copy. In C++ you allways "know" that the class will do the right (deep copy if
needed for the type or shallow copy otherwise).
Perhpas something like Eiffels way of doing it would be the best?

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bvnqbm$24kv$1@digitaldaemon.com...
> >> Unfortunately D doesn't allow you to overload assignment.
> >
> >I have a strong negative view of the value of overloading assignment. By
not
> >overloading it, the semantics of it are reliable and repeatable. (For example, does it do a deep, shallow, or reference copy?)
> >
> Right, you can never no in D.
>
> class Foo (T)
> {
> T data;
> void method (T value)
> {
> data = value;  // what happens?
> }
> }
>
> If T is a class-Type you have a reference copy, if it's not you have a
shallow
> copy. In C++ you allways "know" that the class will do the right (deep
copy if
> needed for the type or shallow copy otherwise).
> Perhpas something like Eiffels way of doing it would be the best?

<g> It is rarely clear in C++ whether one needs to do a deep or a shallow copy. Hence, I just avoid it and use functions to do deep or shallow copies.

><g> It is rarely clear in C++ whether one needs to do a deep or a shallow copy. Hence, I just avoid it and use functions to do deep or shallow copies.

OK, seems like we have different experiences on that. In my hirachies I know whether a object has to perform a deep copy or not by defualt. And depending on that I write the copy-c'tor and the assignment operator.

Walter wrote:

>"Matthias Becker" <Matthias_member@pathlink.com> wrote in message
>news:bvnqbm$24kv$1@digitaldaemon.com...
>  
>
>>>>Unfortunately D doesn't allow you to overload assignment.
>>>>        
>>>>
>>>I have a strong negative view of the value of overloading assignment. By
>>>      
>>>
>not
>  
>
>>>overloading it, the semantics of it are reliable and repeatable. (For
>>>example, does it do a deep, shallow, or reference copy?)
>>>
>>>      
>>>
>>Right, you can never no in D.
>>
>>class Foo (T)
>>{
>>T data;
>>void method (T value)
>>{
>>data = value;  // what happens?
>>}
>>}
>>
>>If T is a class-Type you have a reference copy, if it's not you have a
>>    
>>
>shallow
>  
>
>>copy. In C++ you allways "know" that the class will do the right (deep
>>    
>>
>copy if
>  
>
>>needed for the type or shallow copy otherwise).
>>Perhpas something like Eiffels way of doing it would be the best?
>>    
>>
>
><g> It is rarely clear in C++ whether one needs to do a deep or a shallow
>copy. Hence, I just avoid it and use functions to do deep or shallow copies.
>
>  
>
I think a problem here, is that it's not standardised.  Every time you want to do a copy you need to look up the method in the class.  In one it might be dup(), in another it might by deepcopy().  I think there needs to be something in the language that standardises copying, particularly for templates.


-- 
-Anderson: http://badmama.com.au/~anderson/

[snip]
| ><g> It is rarely clear in C++ whether one needs to do a deep or a shallow
| >copy. Hence, I just avoid it and use functions to do deep or shallow
copies.
| >
| I think a problem here, is that it's not standardised.  Every time you
| want to do a copy you need to look up the method in the class.  In one
| it might be dup(), in another it might by deepcopy().  I think there
| needs to be something in the language that standardises copying,
| particularly for templates.

A consistent naming scheme should be good enough. Since arrays use a "dup" property for a shallow copy I'd just continue using that and have something like "deepdup" for a deep copy. Possibly define a couple of interfaces (Dupable and DeepDupable?) with these properties in them and its all done. Phobos should set the standard.

| --
| -Anderson: http://badmama.com.au/~anderson/