Is C# any good?
TLOlczyk
pieces of C# ( to my suprise ). So si C# any good? If so what makes it
good ( or bad )?
James Rogers
news:e092nvsmcvfpcfk38...@4ax.com:
> Recently I've seen blurbs from reliable places praising bits and
> pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> good ( or bad )?
>
Yes. C# is good for some purposes. This does not mean that it is good
or bad for your needs. You must study the language and your needs to
determine if C# is the proper tool for your uses.
Jim Rogers
Jack Klein
wrote in comp.programming:
> Recently I've seen blurbs from reliable places praising bits and
> pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> good ( or bad )?
Good for what? "good" is not an objective technical term.
Good for certain types of Windows GUI applications? Maybe, I don't
know.
Good for generating a program to fit into 2k bytes of OTP EPROM on an
8-bit microcontroller in an embedded system? Guaranteed not.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
A G Watson
uses seems to be better thought out than the old MFC.
On Wed, 24 Sep 2003 00:00:08 -0500, TLOlczyk <olczy...@yahoo.com>
wrote:
Kevin Cline
> Recently I've seen blurbs from reliable places praising bits and
> pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> good ( or bad )?
It's a huge improvement over writing windows applications with
Visual-C++ and MFC. But it's not as expressive as C++ or Perl or as
open as Java. It's only useful for MS-Windows programming, and
standard or no, I don't imagine that it will ever be used for any
other purpose. The addition of generics will help with the currently
poor type-safety, but C# generics they won't be nearly as powerful as
C++ templates, nor is the collection library any match for the C++
STL.
Fergus Henderson
>It's only useful for MS-Windows programming,
Why do you say that?
There are several C# implementations for other platforms,
in particular Mono and Portable.NET.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
4Space
> Visual-C++ and MFC.
Totally agree.
> But it's not as expressive as C++ or Perl or as
> open as Java. It's only useful for MS-Windows programming, and
> standard or no, I don't imagine that it will ever be used for any
> other purpose.
I'm sure the guys on the Mono project will be disheartened by this :)
> The addition of generics will help with the currently
> poor type-safety, but C# generics they won't be nearly as powerful as
> C++ templates, nor is the collection library any match for the C++
> STL.
The generics in C# will be an order of magnitude better than the C++
generics, insomuch that they can enforce interface conformance for the
templated types. I'm not sure about your comment regarding C# type safety -
it is intrinsically more type safe than C++. I'd be interested in why you
think it isn't, but I suspect we are already on the periphery of what is
on-topic :)
Cheers,
4Space
Michael Feathers
"Kevin Cline" <kcli...@hotmail.com> wrote in message
news:ba162549.03092...@posting.google.com...
Has that ever bitten you in Java or C#? People talk a lot about the danger
of casting out of collections, but I can't remember ever having been bitten
by that.
Michael Feathers
www.objectmentor.com
Michael Feathers
> pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> good ( or bad )?
Decent language. It seems that they took nearly everything that people had
an issue with in Java and did something about it. One part of the language
that I don't care for much is the idea of a 'property.'
TLOlczyk
wrote:
>kcli...@hotmail.com (Kevin Cline) writes:
>
>>It's only useful for MS-Windows programming,
>
>Why do you say that?
>There are several C# implementations for other platforms,
>in particular Mono and Portable.NET.
1) Are they anywhere near complete implementations of C#?
2) I believe when he says MS-Windows programming he means
Windows *GUI* programming.
goose
> pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> good ( or bad )?
it might be, for some purposes. it definately wont be good for *all*
purposes. whether or not it is good or bad is irrelevant. it will
be foisted onto us whether we like it or not, so you may as well
learn it ...
<example>
java wasn't necessarily "good" (for most definitions of "good") when
it was first foisted onto the development world. it was slow, bulky,
resource-hungry and mostly crippled. it offered not a *single* advantage
over the current languages of the time. luckily the sun marketing
machine managed to persuade managers everywhere to start new projects
in java, even though it was mostly inadequate(sp?).
<scary thought>out there in the world, we've got hundreds of
managers who thought to themselves
"no one knows this language, it cannot do what we want properly,
and it will cost of tons of $$$ to retrain developers to work in
it, but lets go ahead and do our new development in it anyway"...
wonder what those managers are fscking up now ...
</scary thought>
moral of the story: even if C# is the biggest load of crap
ever, even if it has trouble with reliability, or security or
plain ol' addition, its here to stay for a while.
if it is bad, it will certainly get better over time.
goose,
resource hungry, again!!!
Joachim Durchholz
> One part of the language
> that I don't care for much is the idea of a 'property.'
Actually, properties are nice for storing meta informaton about a piece
of software. This helps with software repositories (e.g. for searching
by property value), and for some other (IMHO more dubious) things.
I'm not sure whether properties in their current form are already
enough, and they can be misused or used in unhelpful ways, but to the
very least, they give a basis for experimenting with such stuff.
Regards,
Jo
Shayne Wissler
"Michael Feathers" <mfea...@objectmentorNOSPAM.com> wrote in message
news:I5Wcb.6219$pP6....@newsread2.news.atl.earthlink.net...
There's a readability aspect to this too. If the type the container can hold
is part of the declaration, then you don't have to look any further to see
what actually goes in there. Also, the compiler can optimize better if it
knows the type.
Shayne Wissler
William Stacey
"contain" all its data and keep it from direct reference (if needed.)
--
William Stacey
"Michael Feathers" <mfea...@objectmentorNOSPAM.com> wrote in message
news:rqWcb.6256$pP6....@newsread2.news.atl.earthlink.net...
Programmer Dude
> One part of [C#] that I don't care for much is the idea of a
> 'property.'
Maybe it's the VB background, but I rather like them if, for no
other reason, than I find...
my_object.X
...much nicer on the eyes than...
my_object.X()
...(when, in fact, all you are really doing is getting at a value
anyway).
--
|_ CJSonnack <Ch...@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|
Michael Feathers
"Joachim Durchholz" <joachim....@web.de> wrote in message
news:bl1knq$ie4$1...@news.oberberg.net...
I think we're talking about different things... A property in C# looks
like this:
public class Checkbook
{
private int runningBalance = 0;
// a property
public int Balance
{
get { return runningBalance; }
}
}
I think you're talking about attributes. They look like this:
[TestFixture()] // <- an attribute
public class CheckbookTest : Assertion
{
...
}
Michael Feathers
www.objectmentor.com
William Stacey
> Visual-C++ and MFC.
Agreed 100%
> But it's not as expressive as C++ or Perl or as
> open as Java.
I don't really agree with that. C++, yeh. Its also much easier to be
productive. If you have to have C or C++, then write that module with it -
not the whole app. C# also has unsafe code blocks if you need to use
pointers. IMO, it is as expressive as Perl. The one thing they could take
more from Perl is RegEx's built right into the language instead of in the
framework. However, the more you add, the more you change the language and
it starts becoming a closet full of stuff again.
>It's only useful for MS-Windows programming, and
> standard or no, I don't imagine that it will ever be used for any
> other purpose.
You can easily do console apps (client and/or server) or services (no UI.)
It is a great server side object language for remoting or web services.
--
William Stacey
Michael Feathers
"Shayne Wissler" <thalesN...@yahoo.com> wrote in message
news:wNYcb.586343$Ho3.111922@sccrnsc03...
True. I hate all of those casts. On optimization though, seems that you
can get a lot jitting at runtime like some of the Smalltalks do.
Michael Feathers
www.objectmentor.com
Michael Feathers
"William Stacey" <sta...@mvps.org> wrote in message
news:vn8mq9o...@corp.supernews.com...
> Properties are more OO then public fields as they allow the object to
> "contain" all its data and keep it from direct reference (if needed.)
Yes, public fields are bad, so it seems kind of spooky to have a language
feature that attempts to sanitize them but doesn't really leave you better
off in terms of encapsulation. It almost seems like an endorsement.
Michael Feathers
www.objectmentor.com
William Stacey
> off in terms of encapsulation. It almost seems like an endorsement.
What do you mean?
--
William Stacey, DNS MVP
Michael Feathers
> > attempts to sanitize them but doesn't really leave you better
> > off in terms of encapsulation. It almost seems like an endorsement.
>
> What do you mean?
Just that you are better off when present higher level behavior in your
public interface.
It doesn't matter whether you present a public variable, a property or
getters and setters for that variable, its still low-level behavior.
Sometimes you have to do it, but codifying it in a language feature does
feel like an endorsement to me.
There is a big thread on getters and setters which is still active on this
newsgroup. It has much more justfication. It is deep down in "Does MVC
violate OOP?"
Michael Feathers
www.objectmentor.com
Joachim Durchholz
> I think we're talking about different things...
> I think you're talking about attributes. They look like this:
You're right.
Regards,
Jo
Peter Ammon
[...]
>
> The generics in C# will be an order of magnitude better than the C++
> generics, insomuch that they can enforce interface conformance for the
> templated types.
What do you mean by this? How is C++'s implementation lacking in this area?
If C#'s generics are about nothing more than templated types, to get
static type checking of collections, then C++'s templates are a lot more
powerful.
> I'm not sure about your comment regarding C# type safety -
> it is intrinsically more type safe than C++.
Agreed that C# is more type safe than C++. I assume he meant static,
compile time type checking, where C++'s templates get you more than C#
without generics.
> I'd be interested in why you
> think it isn't, but I suspect we are already on the periphery of what is
> on-topic :)
>
> Cheers,
>
> 4Space
-Peter
Peter Ammon
> Michael Feathers wrote:
>
>
>>One part of [C#] that I don't care for much is the idea of a
>>'property.'
>
>
> Maybe it's the VB background, but I rather like them if, for no
> other reason, than I find...
>
> my_object.X
>
> ...much nicer on the eyes than...
>
> my_object.X()
>
> ...(when, in fact, all you are really doing is getting at a value
> anyway).
>
IOW, the syntax for calling a function or method stinks, and stinks all
the way back to C and before.
-Peter
Peter Ammon
> Properties are more OO then public fields as they allow the object to
> "contain" all its data and keep it from direct reference (if needed.)
>
So why have properties at all? Why not simply have accessors?
-Peter
Alf P. Steinbach
The point is very much to facilitate tool support, including design-time
support. Java does it via naming conventions for accessors. But that's
just a _convention_; it's better to have the concept formalized.
(Snipped comp.lang.functional, who put that in there?)
William Stacey
> public interface.
That is what properties are for, so you don't expose members directly and
also allow you to do other stuff like calculations, etc. If you don't use
public fields, and don't use properties, then your left with methods.
Methods are not right for some things. Properties are good and standard OO
stuff.
--
William Stacey
Tomasz Zielonka
> 4Space wrote:
>
> [...]
>>
>> The generics in C# will be an order of magnitude better than the C++
>> generics, insomuch that they can enforce interface conformance for the
>> templated types.
>
> What do you mean by this? How is C++'s implementation lacking in this area?
It's not implementation that is lacking. This is a problem with C++
language definition. Implementations are just following it.
C++ templates can't generally be fully checked in place of definition.
They are checked when instantiated, that is - their _implementation_ is
checked in place of use.
If you are building a library which consists mainly of templates, the
compiler will not even tell you about stupid typos or type mismatches if
you don't instantiate the template. Detection of mistakes is delayed and
when it happens it often shows up in least expected places. For example,
I often was told by the compiler that there is something wrong in
<locale>, which I don't even include explicitly. Compilers report often
exceeded 1MB in size.
Take a look at Haskell, where you can write generic code and it is
type-checked once, in place of definition. What matters in place of use
is function's type signature, not implementation.
Best regards,
Tom
--
.signature: Too many levels of symbolic links
William Stacey
That is what Properties in C# use - getter and setter accessors. Example:
class Square: Shape
{
public double side;
// Constructor:
public Square(double s)
{
side = s;
}
// The Area property
public override double Area
{
get
{
return side*side ;
}
set
{
// Given the area, compute the side
side = Math.Sqrt(value);
}
}
}
In general, methods represent actions and properties represent data.
The following is from MSDN:
"Use a property when the member is a logical data member. In the following
member declarations, Name is a property because it is a logical member of
the class.
[C#]
public string Name
get
{
return name;
}
set
{
name = value;
}
Use a method when:
The operation is a conversion, such as Object.ToString.
The operation is expensive enough that you want to communicate to the user
that they should consider caching the result.
Obtaining a property value using the get accessor would have an observable
side effect.
Calling the member twice in succession produces different results.
The order of execution is important. Note that a type's properties should be
able to be set and retrieved in any order.
The member is static but returns a value that can be changed.
The member returns an array. Properties that return arrays can be very
misleading. Usually it is necessary to return a copy of the internal array
so that the user cannot change internal state. This, coupled with the fact
that a user can easily assume it is an indexed property, leads to
inefficient code. In the following code example, each call to the Methods
property creates a copy of the array. As a result, 2n+1 copies of the array
will be created in the following loop. "
Daniel Parker
Regards,
Daniel Parker
William Stacey
month, day properties would be natural for a date class (e.g. the framework
DateTime class.)
--
William Stacey, DNS MVP
"Daniel Parker" <daniel...@windupbird.com> wrote in message
news:GI6db.6418$7w5.4...@news20.bellglobal.com...
Uncle Bob (Robert C. Martin)
on (or about) Wed, 24 Sep 2003 00:00:08 -0500, :
>Recently I've seen blurbs from reliable places praising bits and
>pieces of C# ( to my suprise ). So si C# any good? If so what makes it
>good ( or bad )?
The language and environment are quite nice. The development tools
have a ways to go to catch up with Java. If you have used IntelliJ or
Eclipse for Java you know what I mean.
C# is essentially Java. There are a few differences, but most are not
important. The .NET environment is similar in many ways to the Java 2
environment. Again, there are differences but none of them are
"makers" or "breakers".
The choice between java and .net is not a technological decision.
It's a political one that strongly resembles the IBM vs. DEC decision
of thirty years ago, or the IBM vs COMPAQ decision of fifteen years
ago. Or the Microsoft vs. Apple decision of 10 years ago.
Some people value innovation, and some value presence. Some value
agility, and some value stability.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python | http://fitnesse.org
Michael Feathers
"Daniel Parker" <daniel...@windupbird.com> wrote in message
news:GI6db.6418$7w5.4...@news20.bellglobal.com...
I like dates as value objects rather than reference objects, so yes, it
would need getters for those, but no setters. Properties seem like
overkill.
Michael Feathers
www.objectmentor.com
Michael C. Ferguson
<u.n.c.l...@objectmentor.com> wrote:
>C# is essentially Java. There are a few differences, but most are not
>important. The .NET environment is similar in many ways to the Java 2
>environment. Again, there are differences but none of them are
>"makers" or "breakers".
Well.. I think they can be -- please see below...
>The choice between java and .net is not a technological decision.
>It's a political one that strongly resembles the IBM vs. DEC decision
>of thirty years ago, or the IBM vs COMPAQ decision of fifteen years
>ago. Or the Microsoft vs. Apple decision of 10 years ago.
>
>Some people value innovation, and some value presence. Some value
>agility, and some value stability.
IMHO, the driving factor in your choice of C# or Java should be that
of your target platform. If you're targeting a client environment that
is already saturated with Windows and MS products (as is the case...
basically everywhere), it is greatly to your behoove to use C# and the
MS Libraries. Although many of the older MS APIs are, well, crap, they
do at least exist and are very thoroughly documented (if not by MS,
then by the throngs of people who have also been forced to use them).
On the other hand, Java is severely lacking in the same general
OS-level features; being a few steps closer to the host OS can be a
tremendous benefit when, for example, you want to integrate scanning
(via WIA or TWAIN), Tablet API features, etc. Or maybe you just want
your application to 'fit' into the general look and feel of the host
OS, which Java never really does effectively (even with the new,
much-needed 1.4.2 changes)...
Java does have the capability to utilize non-native libraries via JNI.
But JNI is buggy, a PITA, and it compromises the homogeneity of your
architecture, which is sure to bite you in the ass somewhere down the
line. That said, and having programmed in both Java and C#/.NET for
major projects, I do prefer the Java language and API over C#/.NET.
But being pragmatic, I will use whatever comes closest to the
specifications of the project environment with the least hassle and
worry. IMHO, there are very real overriding reasons to choose both
Java and C#, and they should be seriously considered, not written off
as politics.
Best regards,
-- mcf
P.S. This post aside :P I have really enjoyed reading your posts on
comp.object, esp. in regards to get/set, UML, etc. I hope your book on
Agile developement is as good as your usenet posts, since it's on its
way from Amazon. :)
Joachim Durchholz
> That is what Properties in C# use - getter and setter accessors.
Note that having a getter *and* a setter makes it impossible to redefine
the type of the property in a subclass.
Such a redefinition is not a problem if the property can only be set in
the constructor, which essentially means that you can have flexible
subtyping only if the data is immutable.
Which is one of the major reasons why I'm talking from a
functional-language point of perspective :-)
Regards,
Jo
Joachim Durchholz
>> Michael Feathers wrote:
>>
>> Maybe it's the VB background, but I rather like them if, for no
>> other reason, than I find...
>>
>> my_object.X
>>
>> ...much nicer on the eyes than...
>>
>> my_object.X()
>>
>> ...(when, in fact, all you are really doing is getting at a value
>> anyway).
>
> IOW, the syntax for calling a function or method stinks, and stinks all
> the way back to C and before.
I have seen two ways to avoid this stinking:
1) The Eiffel way: just don't write an empty pair of parentheses. In
other words, the caller code is never modified if the implementation is
changed from parameterless function to attribute or vice versa. (Such
conventions would benefit any language, whether it's OO, functional, or
anything else.)
2) The Haskell way, which is in turn based on typical mathematical
conventions: don't write parentheses for function calls at all. sin x is
the sine of x, no parentheses needed. sin x + 4 is the same as
(sin x) + 4, if you want it the other way round you have to write
sin (x + 4).
For multi-parameter functions, you still don't have commas or anything.
foo a b if the function foo, applies to the parameters a and b; if a is
a function call itself, you have to add parentheses and get
foo (goo x) b, since foo goo x b would be ((foo goo) x) b which is
usually not what one wanted.
The first solution is a bit awkward since it needs special rules, but it
solves the basic problem very well (I have programmed in Eiffel for
three years and seen it work).
The second solution goes against programming tradition, and it requires
a bit getting used to. However, omitting all these parentheses and
commas does have an amazing impact on code compactness.
Regards,
Jo
Dave Harris
> > Maybe it's the VB background, but I rather like them if, for no
> > other reason, than I find...
> >
> > my_object.X
> >
> > ...much nicer on the eyes than...
> >
> > my_object.X()
> >
> > ...(when, in fact, all you are really doing is getting at a value
> > anyway).
> >
>
> IOW, the syntax for calling a function or method stinks, and stinks all
> the way back to C and before.
Agreed. It's perhaps worth pointing out that in BCPL, C and C++, functions
are values too. Both:
p = x;
p = x();
are valid and the brackets are needed to say which you mean. Also, in C++
it is possible to take the address of a function return, so:
p = &x;
p = &x();
are valid and different too.
-- Dave Harris, Nottingham, UK
William Stacey
what you mean using properites?
--
William Stacey, DNS MVP
"Joachim Durchholz" <joachim....@web.de> wrote in message
news:bl6gnr$o0k$1...@news.oberberg.net...
Joachim Durchholz
> Did not follow that completely. Could you provide a short code
> example of what you mean using properites?
Sure.
Assume class Foo with the property item: Ellipse, or, equivalently, the
routines
set_item (e: Ellipse)
get_item: Ellipse
Now let's have a subclass Bar that wants to redefine the item into a
Circle. (For now, I'll just assume that every Circle is-an Ellipse.)
The property resp. the implicit getter and setter routines will stay
essentially the same, with Circle instead of Ellipse.
Now assume the following code snippet:
baz (new Bar, new Ellipse);
...
function baz (foo: Foo, e: Ellipse)
foo.item := e -- Assigning an Ellipse to a Circle property
What went wrong?
Redefining the get_item routine was OK: If baz accesses a Foo object and
gets a Bar one instead, it will retrieve a Circle instead of an Ellipse,
but since every Circle is-an Ellipse, that's OK.
However, the redefinition of the set_item routine violated the Liskov
Substitution Principle: in the superclass, it would work properly with
any Ellipse, but now in the subclass, it would insist on getting a
Circle and nothing else!
In other words, parameters may only be redefined to supertypes (not that
this is very useful in the general case). If you have a property, where
the same type must occur in a parameter and a result position, you
cannot redefine because the occurrence of the type in a parameter
position forbids redefining as a subtype, and the occurrence in a result
position forbids redefining as a supertype.
(Of course, you can still write a subclass. However, the language must
not treat such a subclass as a substitutable subtype if it wishes to
avoid type holes.
C++ doesn't allow parameter type redefinitions as all. Eiffel allows
them and gets type holes. Choose your problem...)
Regards,
Jo
Aaron Denney
In article <I5Wcb.6219$pP6....@newsread2.news.atl.earthlink.net>, Michael Feathers wrote:
> Has that ever bitten you in Java or C#? People talk a lot about the danger
> of casting out of collections, but I can't remember ever having been bitten
> by that.
It's usually not a problem if you immediately test the code you've
written and only keep one type of object in a Collection. I have had it
bite me, though. Someone else wrote some small glue code that never got
tested until I looked at the interface and decided "hey that's exactly
what I need!", and prompty caused a clash on the next run.
--
Aaron Denney
-><-
Gerry Quinn
>The second solution goes against programming tradition, and it requires
>a bit getting used to. However, omitting all these parentheses and
>commas does have an amazing impact on code compactness.
Now we just need an explanation of why code compactness is good...
Gerry Quinn
--
http://bindweed.com
Kaleidoscopic Screensavers and Games for Windows
Download free trial versions
New screensaver: "Hypercurve"
Donald Roby
> In article <bl6h8p$o8u$1...@news.oberberg.net>, Joachim Durchholz
> <joachim....@web.de> wrote:
>
>>The second solution goes against programming tradition, and it requires
>>a bit getting used to. However, omitting all these parentheses and
>>commas does have an amazing impact on code compactness.
>
> Now we just need an explanation of why code compactness is good...
>
> Gerry Quinn
Concise and clear code is good.
Compact code can however be extremely unclear.
There are plenty of signatures in comp.lang.perl.misc to prove this point.
Examples can also be done quite effectively in APL.
And of course, such obfuscation can be done in any language.
Universe
> William Stacey wrote:
Why couldn't one handle getter/setter values as e.g string values and
internally convert to whatever the type of the "actual" data member may
be at any point in time?
"setting" the value to be cubed for a class whose responsibility is to
cube or perform some set of math operations that includes "cubing" would
seem to make perfect sense.
Underlining as I see things that "getter/setter" are bad in class
interface when getter/setter are primary or significant "determinants"
in *how* a class executes, performs, its designed responsibility.
Hence "getter/setters" are bad when they are primary or significant
"determinants" in *how* a class _method_ carries out one of the set of
class behaviors. All class method behaviors in sum comprise, make
possible, the overall classes responsibility.
Elliott
--
*~* Theory Leads, Practice Verifies *~*
*~* Global Plans + IID (Iterative & Incremental Development) *~*
Joachim Durchholz
> "Joachim Durchholz" <joachim....@web.de> wrote:
>
>>William Stacey wrote:
>>
>>>That is what Properties in C# use - getter and setter accessors.
>>Note that having a getter *and* a setter makes it impossible to redefine
>>the type of the property in a subclass.
>>Such a redefinition is not a problem if the property can only be set in
>>the constructor, which essentially means that you can have flexible
>>subtyping only if the data is immutable.
>>Which is one of the major reasons why I'm talking from a
>>functional-language point of perspective :-)
>
> Why couldn't one handle getter/setter values as e.g string values and
> internally convert to whatever the type of the "actual" data member may
> be at any point in time?
If you do that systematically, you arrive at a typeless language,
because ultimately all parameters are candidates for redefinition.
Which is entirely feasible, that language already exists under the name
of Smalltalk :-)
Of course, you lose all advantages of static typing. The challenge is
designing a good static type system for OO languages, one that is both
sound (free of type holes) and expressive enough.
Unfortunately, subtyping alone isn't enough, at least if you have
mutable data. You need something powerful, like template programming
(which aren't checkable unless instantiated - bad for testing the
template library before it's used), parameterized types of various
kinds, etc.
<plug> Most functional languages have such a type system. Actually, they
don't use subtyping at all, generics do everything that's needed in
practice. </plug>
Regards,
Jo
Isaac Gouy
-SNIP-
> If you do that systematically, you arrive at a typeless language,
> because ultimately all parameters are candidates for redefinition.
>
> Which is entirely feasible, that language already exists under the name
> of Smalltalk :-)
Smalltalk is not typeless - types are not statically checked, they are
checked at runtime. (Which makes Smalltalk 'safe' - unlike C)
> Of course, you lose all advantages of static typing. The challenge is
> designing a good static type system for OO languages, one that is both
> sound (free of type holes) and expressive enough.
> Unfortunately, subtyping alone isn't enough, at least if you have
> mutable data. You need something powerful, like template programming
> (which aren't checkable unless instantiated - bad for testing the
> template library before it's used), parameterized types of various
> kinds, etc.
> <plug> Most functional languages have such a type system. Actually, they
> don't use subtyping at all, generics do everything that's needed in
> practice. </plug>
Is the challenge answered by Nice?
http://nice.sourceforge.net/research.html
Joachim Durchholz
>>because ultimately all parameters are candidates for redefinition.
>>
>>Which is entirely feasible, that language already exists under the name
>>of Smalltalk :-)
>
> Smalltalk is not typeless - types are not statically checked, they are
> checked at runtime.
Whatever.
Read the context to discern the meaning :-)
> (Which makes Smalltalk 'safe' - unlike C)
Sort of.
Smalltalk still has failure modes, but they are easier to control and
*much* easier to recover from.
>><plug> Most functional languages have such a type system. Actually, they
>>don't use subtyping at all, generics do everything that's needed in
>>practice. </plug>
>
> Is the challenge answered by Nice?
> http://nice.sourceforge.net/research.html
Things that I don't like about Nice, unrelated to subtyping:
Multiple dispatch, while powerful, has modularity issues. (I don't think
a good solution exists. When I ever manage to get my WWW site up, I'll
publish my thoughts on the subject.)
Better solutions exist for the problems that the existence of Null
solves; I find the presentation of Nice's ? types as a design advantage
mildly irritating (it reminds me of early C advocates who fiercely
defended special operators like += and ++ as great improvements - better
solutions exist, and the solved problems aren't so general after all; I
expect a similar fate for ? types).
Defining an automatic constructor that initialized all fields from
parameters exposes implementations details.
Parametric classes should accept values as well as types. Programmers
want to write declaration like Vector<Integer, 3>.
Things that I don't like about the Nice User's Manual, and related to
the typing issues:
There is no mention of what constitutes a subtype.
I'll have to take a deeper look at the research papers; they are too
long for a short exchange on a newsgroup.
Independent of Nice, I think that subtyping is an important concept, but
that the OO practice of assuming that most code reuse will
almost-automatically produce a subtype is too optimistic. It starts with
the observation that having mutable data destroys almost all
opportunities for having an interesting subtype. (I have no idea whether
the Nice design fell to that trap or not. As I said: I'll have to read
the papers.)
Regards,
Jo
Marcin 'Qrczak' Kowalczyk
> Multiple dispatch, while powerful, has modularity issues. (I don't think
> a good solution exists. When I ever manage to get my WWW site up, I'll
> publish my thoughts on the subject.)
These modularity issues are intrinsic to the problem, not to the solution.
Emulating multiple dispatch with repeated single dispatch or with typecase
yields yet less maintainable code.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Isaac Gouy
-SNIP-
> >><plug> Most functional languages have such a type system. Actually, they
> >>don't use subtyping at all, generics do everything that's needed in
> >>practice. </plug>
> >
> > Is the challenge answered by Nice?
> > http://nice.sourceforge.net/research.html
>
> Things that I don't like about Nice, unrelated to subtyping:
The language authors seem happy to receive feedback on language
design, please tell them what you like or don't like on the Nice
mailing list.
> Multiple dispatch, while powerful, has modularity issues. (I don't think
> a good solution exists. When I ever manage to get my WWW site up, I'll
> publish my thoughts on the subject.)
I'm curious to hear what the problems are.
> Better solutions exist for the problems that the existence of Null
> solves; I find the presentation of Nice's ? types as a design advantage
> mildly irritating (it reminds me of early C advocates who fiercely
> defended special operators like += and ++ as great improvements - better
> solutions exist, and the solved problems aren't so general after all; I
> expect a similar fate for ? types).
I'm curious to hear about the better solutions (particularly in the
context of an OO language).
> Defining an automatic constructor that initialized all fields from
> parameters exposes implementations details.
Tend to agree.
> Parametric classes should accept values as well as types. Programmers
> want to write declaration like Vector<Integer, 3>.
I'm not very clever, could you spell out what that would do please?
> Things that I don't like about the Nice User's Manual, and related to
> the typing issues:
It's out-of-date and incomplete (guess someone could offer to update
it)
Neelakantan Krishnaswami
> Joachim Durchholz <joachim....@web.de> wrote
>
>> solves; I find the presentation of Nice's ? types as a design advantage
>> mildly irritating (it reminds me of early C advocates who fiercely
>> defended special operators like += and ++ as great improvements - better
>> solutions exist, and the solved problems aren't so general after all; I
>> expect a similar fate for ? types).
>
> I'm curious to hear about the better solutions (particularly in the
> context of an OO language).
Given that Nice wants to coexist with Java, I don't think there is a a
better solution -- Java has null, and a language that cohabits with it
must rationalize that (for both meanings of rationalize!).
If you don't have that constraint, then the right thing to do is to
ensure that you can't write constructors that leave fields un-
initialized. What I planned (but didn't implement) for Needle was an
idea stolen from John Reppy's Moby language. The idea is to define a
new syntactic class for constructor functions, like this:
class SizedList[a] {
head a;
tail SizedList[a];
size Integer;
}
constructor cons . (h a, t List[a]) -> SizedList[a] {
field head = h;
field tail = t;
let new_size = t.size + 1;
field size = new_size;
}
Constructors are called and passed around just like regular functions,
but have a slightly different definition syntax. You can write field
initializer expressions in the constructor, and the compiler does an
easy check that all of the fields in the class get initialized, or it
rejects the constructor.
>> Defining an automatic constructor that initialized all fields from
>> parameters exposes implementations details.
>
> Tend to agree.
This problem really gets magnified if you want to have parameterized
modules in your language.
--
Neel Krishnaswami
ne...@cs.cmu.edu
Marcin 'Qrczak' Kowalczyk
> If you don't have that constraint, then the right thing to do is to
> ensure that you can't write constructors that leave fields un-
> initialized.
In my yet unfinished language (dynamically typed, mostly functional)
constructors define what fields are present. With your example, completed
to empty list:
type SizedList {
type ConsSized;
type EmptySized;
};
def consSized h t = new ConsSized object {
let head = h;
let tail = t;
let size = t.size + 1;
};
let emptySized = new EmptySized object {let size = 0};
Constructors are normal functions, they only happen to use the primitive
type-tagging construct 'new Type expr' which doesn't even have to be used
inside a function, as seen in the emptySized constant. This construct must
be used however in the same module as the type defininition, so external
code can't make fake objects of that type. The 'new Type expr' syntax only
attaches a type tag; 'object {...}' is what makes an object with fields.
Fields can be immutable since beginning because they are born initialized.
Daniel Yokomiso
news:slrnbnrkdo...@gs3106.sp.cs.cmu.edu...
In Eon (my designed but unimplemented language) classes don't define
structure, just the interface, so there's no need for a special
"constructor" operation, just a object literal:
class SizedList a := {
head (self : a SizedList) : a;
tail (self : a SizedList) : a SizedList;
size (self : a SizedList) : Integer;
empty : a SizedList
};
empty : a SizedList := {head := error; tail := error; size := 0};
cons h t := {head := h; tail := t; size := t size + 1};
The class define all operations that should be implemented by either method
declarations (e.g. "empty") or by the object. IMO object literals are very
useful and removing structure information from classes makes subtyping
easier (i.e. you won't have a subclass with unused fields, like "empty" in
this case).
> >> Defining an automatic constructor that initialized all fields from
> >> parameters exposes implementations details.
> >
> > Tend to agree.
>
> This problem really gets magnified if you want to have parameterized
> modules in your language.
>
> --
> Neel Krishnaswami
> ne...@cs.cmu.edu
Best regards,
Daniel Yokomiso.
"Quidquid latine dictum sit, altum sonatur."
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 30/9/2003
"Neelakantan Krishnaswami" <ne...@cs.cmu.edu> escreveu na mensagem
news:slrnbnrkdo...@gs3106.sp.cs.cmu.edu...
In Eon (my designed but unimplemented language) classes don't define
structure, just the interface, so there's no need for a special
"constructor" operation, just a object literal:
class SizedList a := {
head (self : a SizedList) : a;
tail (self : a SizedList) : a SizedList;
size (self : a SizedList) : Integer;
empty : a SizedList
};
empty : a SizedList := {head := error; tail := error; size := 0};
cons h t := {head := h; tail := t; size := t size + 1};
The class define all operations that should be implemented by either method
declarations (e.g. "empty") or by the object. IMO object literals are very
useful and removing structure information from classes makes subtyping
easier (i.e. you won't have a subclass with unused fields, like "empty" in
this case).
> >> Defining an automatic constructor that initialized all fields from
> >> parameters exposes implementations details.
> >
> > Tend to agree.
>
> This problem really gets magnified if you want to have parameterized
> modules in your language.
>
> --
> Neel Krishnaswami
> ne...@cs.cmu.edu
Best regards,
Daniel Yokomiso.
"Quidquid latine dictum sit, altum sonatur."
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 30/9/2003
Franck Arnaud
> > Multiple dispatch, while powerful, has modularity issues. (I don't think
> > a good solution exists. When I ever manage to get my WWW site up, I'll
> > publish my thoughts on the subject.)
> I'm curious to hear what the problems are.
For a multiply dispatched function f (a:A,b:B) you have
number_of_subtypes (A) * number_of_subtypes (B) possible
combinations of calls that may need to be dispatched.
You can:
- require exhaustive declarations for all cases.
Problem: you have lots of declarations, most of whom say
very little. Every time you add a A subtype, you need
to add number_of_subypes (B) declarations for f.
- be non exhaustive, and have a scheme to find
the 'nearest' declared implementation for each
implicit case.
Problem: can you find an algorithm that does not
produce incorrect and unexpected matches? Adding
or removing a declaration for f, or changing the
shape of the A or B subtyping trees, may have
unexpected effects on unrelated (to the
programmer) cases which are then caught by the
wrong handler.
- be non exhaustive, and fail at runtime on any
undeclared applications.
Problem: not statically type safe.
- require system wide exhaustiveness,
that is require explicit declarations for
the subset of all cases deducted from a static
analysis of all call sites of f.
Problem: requires closed world, and any unexpected
use of f by a client will require new declarations
on the supplier side.
Fergus Henderson
>Fergus Henderson <f...@cs.mu.oz.au> wrote:
>
>>kcli...@hotmail.com (Kevin Cline) writes:
>>
>>>It's only useful for MS-Windows programming,
>>
>>Why do you say that?
>>There are several C# implementations for other platforms,
>>in particular Mono and Portable.NET.
>
>1) Are they anywhere near complete implementations of C#?
Yes.
Here's an extract from the Mono web site <http://www.go-mono.com/c-sharp.html>:
| The Mono C# compiler is considered feature complete at this point and
| relatively mature. MCS is able to compile itself and many more C# programs
| (there is a test suite included that you can use). It is routinely used
| to compile Mono, roughly half a million lines of C# code.
I think the Portable.NET C# compiler is similar.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Kevin Cline
> "Kevin Cline" <kcli...@hotmail.com> wrote in message
> news:ba162549.03092...@posting.google.com...
> > TLOlczyk <olczy...@yahoo.com> wrote in message
> news:<e092nvsmcvfpcfk38...@4ax.com>...
> > > Recently I've seen blurbs from reliable places praising bits and
> > > pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> > > good ( or bad )?
> >
> > Visual-C++ and MFC. But it's not as expressive as C++ or Perl or as
> > open as Java. It's only useful for MS-Windows programming, and
> > standard or no, I don't imagine that it will ever be used for any
> > other purpose. The addition of generics will help with the currently
> > poor type-safety, but C# generics they won't be nearly as powerful as
> > C++ templates, nor is the collection library any match for the C++
> > STL.
>
> Has that ever bitten you in Java or C#? People talk a lot about the danger
> of casting out of collections, but I can't remember ever having been bitten
> by that.
Nor can I, but I've seen it happen quite often in moderately large C
applications and expect to see the same thing if C# applications ever
grow large.
Kevin Cline
> TLOlczyk <olczy...@yahoo.com> might (or might not) have written this
> on (or about) Wed, 24 Sep 2003 00:00:08 -0500, :
>
> >Recently I've seen blurbs from reliable places praising bits and
> >pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> >good ( or bad )?
>
> The language and environment are quite nice. The development tools
> have a ways to go to catch up with Java. If you have used IntelliJ or
> Eclipse for Java you know what I mean.
>
> C# is essentially Java. There are a few differences, but most are not
> important. The .NET environment is similar in many ways to the Java 2
> environment. Again, there are differences but none of them are
> "makers" or "breakers".
>
> The choice between java and .net is not a technological decision.
I've run into enough bugs in the .NET libraries to think that it may
be a technological decision. We've just found that certain Windows.Forms
controls are registered globally, and never un-registered,
even when the containing form is closed. The control event handler
points to the containing form, so the old forms just pile up never
to be GC'd. IMO, the .NET technology is not yet ready for prime time.
Peter Ammon
>>So why have properties at all? Why not simply have accessors?
>
>
> That is what Properties in C# use - getter and setter accessors.
Does this level of indirection buy you anything?
Mr. Steinbach indicates that it's to facilitate tool support, which
makes some sense. But you don't need properties for this; look, for
example, at Apple's key-value coding.
> Example:
> class Square: Shape
> {
> public double side;
>
> // Constructor:
> public Square(double s)
> {
> side = s;
> }
> // The Area property
> public override double Area
> {
> get
> {
> return side*side ;
> }
> set
> {
> // Given the area, compute the side
> side = Math.Sqrt(value);
> }
> }
> }
>
> In general, methods represent actions and properties represent data.
Ok, but I'm not sure that formalizing this into the language is worth
the added complexity. Pascal made a not so dissimilar distinction,
between functions and procedures, and it didn't prove very useful.
There's another objection: apparently innocuous code can suddenly have
side effects. This is rampant in C++, where simply declaring a variable
can invoke arbitrary code[1]; I hope C# doesn't head down that same path.
[...]
> The member returns an array. Properties that return arrays can be very
> misleading. Usually it is necessary to return a copy of the internal array
> so that the user cannot change internal state. This, coupled with the fact
> that a user can easily assume it is an indexed property, leads to
> inefficient code. In the following code example, each call to the Methods
> property creates a copy of the array. As a result, 2n+1 copies of the array
> will be created in the following loop. "
Why more languages don't distinguish between mutable and immutable
arrays is beyond me.
-Peter
[1]: You might object that it's the programmer's responsibility to
ensure that his or her classes never do unexpected things. But this
isn't sufficient. For example, in the C++ code:
string foo;
for (;;) {
if (! (cin >> foo)) return 0;
}
moving the string declaration inside the loop produces a dramatic
slowdown (~25 percent), despite being logically equivalent. Client
programmers will need to be aware of at least some of your
implementation details, despite your best efforts.
Michael C. Ferguson
wrote:
I've heard of this type of bad GC behavior seriously affecting older
.NET platforms like 98 and ME. Since they don't have good process
separation, the entire OS bogs down and suffers from the memory leaks.
:( It is definitely something to consider for high-uptime,
high-availability apps.
-- mcf
Joachim Durchholz
> Pascal made a not so dissimilar distinction,
> between functions and procedures, and it didn't prove very useful.
Actually, the distinction proved so useful that it was introduced during
language evolution: a function returning void is just a procedure by
another name.
> There's another objection: apparently innocuous code can suddenly have
> side effects. This is rampant in C++, where simply declaring a variable
> can invoke arbitrary code[1]; I hope C# doesn't head down that same path.
The problem isn't that arbitrary code can be invoked, it's that such
code can have side effects.
Distinguish between "pure function" and "functions with potential side
effects", allow only pure functions within constructors, and the serious
problems are gone.
> Why more languages don't distinguish between mutable and immutable
> arrays is beyond me.
Because you can't fill an immutable array using a loop.
Also, immutability is a complex concept if immutable data can reference
mutable blocks.
Then there's the problem of how to specify apparent immutability (i.e.
when internals of a data structure can change, but the callers will
never be able to detect them).
I haven't seen a good design for mixing mutability and immutability yet.
("Uniqueness types" are one approach that might work, but I haven't seen
enough of that to have an opinion worth talking about.)
Regards,
Jo
Isaac Gouy
> Isaac Gouy:
>
> > > Multiple dispatch, while powerful, has modularity issues. (I don't think
> > > a good solution exists. When I ever manage to get my WWW site up, I'll
> > > publish my thoughts on the subject.)
> > I'm curious to hear what the problems are.
>
> For a multiply dispatched function f (a:A,b:B) you have
> number_of_subtypes (A) * number_of_subtypes (B) possible
> combinations of calls that may need to be dispatched.
> You can:
>
> - require exhaustive declarations for all cases.
> Problem: you have lots of declarations, most of whom say
> very little. Every time you add a A subtype, you need
> to add number_of_subypes (B) declarations for f.
>
> - be non exhaustive, and have a scheme to find
> the 'nearest' declared implementation for each
> implicit case.
> Problem: can you find an algorithm that does not
> produce incorrect and unexpected matches?
The developers of Nice, state that they have an algorithm that
produces correct matches. Unexpected matches? Well if you understand
what the lookup does...?
> Adding
> or removing a declaration for f, or changing the
> shape of the A or B subtyping trees, may have
> unexpected effects on unrelated (to the
> programmer) cases which are then caught by the
> wrong handler.
Isn't this to do with OO rather than multiple dispatch?
What are you getting at?
Daniel Bonniot
Hi,
I am the author of Nice. Somebody pointed me to this discussion, so I
thought I could give some precisions.
Joachim Durchholz wrote:
> Things that I don't like about Nice, unrelated to subtyping:
>
> Multiple dispatch, while powerful, has modularity issues. (I don't think
> a good solution exists. When I ever manage to get my WWW site up, I'll
> publish my thoughts on the subject.)
Do you have a URL ready?
> Better solutions exist for the problems that the existence of Null
> solves;
Are you thinking of ML option type (type 'a option = None | Some of a) ?
In that case, there is a good motivation for Nice's ? types over this
sum type: in Nice, you have the subtyping T <: ?T. This allows to use a
non-null value when a possibly-null value is expected. With the sum type
the user needs to manually wrap and unwrap values out of the sum type.
> Defining an automatic constructor that initialized all fields from
> parameters exposes implementations details.
You are perfectly right that implementation details should not be
exposed. There is work in progress to enable this, by allowing custom
constructors to be defined (which could have the same public interface
as the automatic constructor, to make the modification of fields
irrelevant for clients) and the automatic constructor to be private.
Discussion in progress on
http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NiceConstructors and
http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/CustomConstructors
> Parametric classes should accept values as well as types. Programmers
> want to write declaration like Vector<Integer, 3>.
Indeed, this is not supported. However, I also think that C++ templates
are too "powerful" (meaning that they cannot be typechecked at template
declaration, and therefore delay error reports) so the good balance is
hard to find.
Probably this kind of feature can be obtained with well-behaved macros,
which I think are rather orthogonal with generic types.
> Things that I don't like about the Nice User's Manual, and related to
> the typing issues:
>
> There is no mention of what constitutes a subtype.
You're right, this should indeed be there. In a nutshell: subtyping is
declared. Parameterized classes are normally invariant, but can be
declared co- or contra-variant when it is safe to do so. Tuple and
function types follow the usual rules. Array types are invariant, so
they are statically safe.
> Independent of Nice, I think that subtyping is an important concept, but
> that the OO practice of assuming that most code reuse will
> almost-automatically produce a subtype is too optimistic. It starts with
> the observation that having mutable data destroys almost all
> opportunities for having an interesting subtype.
We're trying to get both worlds in Nice. For instance, mutable fields
can not get a more precise type in a subclass, but immutable fields can.
Concerning methods, multi-methods solve elegantly the
subclassing-is-not-subtyping dilema. This has been known for a long
time, but unfornately this knowledge is not widespread.
Daniel
Daniel Bonniot
> Given that Nice wants to coexist with Java, I don't think there is a a
> better solution -- Java has null, and a language that cohabits with it
> must rationalize that (for both meanings of rationalize!).
>
> If you don't have that constraint, then the right thing to do is to
> ensure that you can't write constructors that leave fields un-
> initialized.
Null can be used beyond "this field is not initialized". It can also be
useful for representing an optional value. For instance, a function with
several optional arguments could be defined as:
void foo(String required, ?int opt1 = null, ?String opt2 = null)
{ ... }
One could do this equivalently with overloaded versions of foo, but
their number grows exponentially with the number of optional arguments,
so it can become impractical.
One could also define a
class Optional<T> {}
class None<T> extends Optional<T> {}
class Some<T> extends Optional<T> { T value; }
The drawback is that calling the function becomes cumbersome:
foo("ABC", new Some(2));
instead of simply
foo("ABC", 2);
in Nice with ? types.
Daniel
Kevin Cline
It can seriously affect any .NET platform if a process is growing 40
Mb per hour, and is expected to stay up for an eight-hour shift. What
really surprises me is that this bug wasn't been discovered and fixed
long ago.
emerth
> pieces of C# ( to my suprise ). So si C# any good? If so what makes it
> good ( or bad )?
As has been noted elsewhere, the Taiwanese AMD girl featured recently
on theinquirer.net website front page is clearly filled with goodness.
But her goodness is not the goodness you want from a
programming language.
Nor her badness, I suspect...
heheheheh
Aaron Denney
> Joachim Durchholz wrote:
>> Parametric classes should accept values as well as types. Programmers
>> want to write declaration like Vector<Integer, 3>.
>
> Indeed, this is not supported. However, I also think that C++ templates
> are too "powerful" (meaning that they cannot be typechecked at template
> declaration, and therefore delay error reports) so the good balance is
> hard to find.
It seems to me that this is more a problem with C++ than with allowing
constant integral values in parametrized types. Consider that you can
church-encode integers into types (other encodings are possible too,
of course). See Okasaki's papers on statically guaranteeing square
matrices at compile-time, or guaranteeing that only vectors of the same
size are considered the same type.
Joachim Durchholz
>
> Joachim Durchholz wrote:
>
>> Things that I don't like about Nice, unrelated to subtyping:
>>
>> Multiple dispatch, while powerful, has modularity issues. (I don't
>> think a good solution exists. When I ever manage to get my WWW site
>> up, I'll publish my thoughts on the subject.)
>
> Do you have a URL ready?
Not yet - other things keep interfering.
But I'll post on comp.lang.functional when a new article appears.
>> Better solutions exist for the problems that the existence of Null
>> solves;
>
> Are you thinking of ML option type (type 'a option = None | Some of a) ?
Indeed.
> In that case, there is a good motivation for Nice's ? types over this
> sum type: in Nice, you have the subtyping T <: ?T. This allows to use a
> non-null value when a possibly-null value is expected. With the sum type
> the user needs to manually wrap and unwrap values out of the sum type.
There isn't much wrapping going on in practice. In general, to work with
a value, you do a pattern match anyway.
>> Defining an automatic constructor that initialized all fields from
>> parameters exposes implementations details.
>
> You are perfectly right that implementation details should not be
> exposed. There is work in progress to enable this, by allowing custom
> constructors to be defined (which could have the same public interface
> as the automatic constructor, to make the modification of fields
> irrelevant for clients) and the automatic constructor to be private.
That's good news.
>> Parametric classes should accept values as well as types. Programmers
>> want to write declaration like Vector<Integer, 3>.
>
> Indeed, this is not supported. However, I also think that C++ templates
> are too "powerful" (meaning that they cannot be typechecked at template
> declaration, and therefore delay error reports) so the good balance is
> hard to find.
C++ templates have two unrelated undesirable properties:
1) Template instantiation may not terminate (this is why some depth in
the instantiation process was limited by the standard, at least AFAIK).
C++ templates share this property with the type systems of some other
languages; for some language, it isn't know whether their type checking
could get into an infinite loop given overly intricate type relationships.
2) Templates aren't type checked at the point of declaration. This is
the larger problem, and a problem unrelated to adding values as template
parameters.
> Probably this kind of feature can be obtained with well-behaved macros,
> which I think are rather orthogonal with generic types.
Actually, they are quite nonorthogonal. Vector<3> is different from
Vector<4> (actually it's a subtype of Vector<4>, a property that would
have to be inferred from the source code - probably it would be best if
Vector<N> were defined in terms of Vector<N-1>, that would make the
inference easy).
>> Independent of Nice, I think that subtyping is an important concept,
>> but that the OO practice of assuming that most code reuse will
>> almost-automatically produce a subtype is too optimistic. It starts
>> with the observation that having mutable data destroys almost all
>> opportunities for having an interesting subtype.
>
> We're trying to get both worlds in Nice. For instance, mutable fields
> can not get a more precise type in a subclass, but immutable fields can.
That's a good conservative approximation. It's even better if Nice
encourages the use of immutable fields.
Regards,
Jo
Jacques Garrigue
> Neelakantan Krishnaswami wrote:
> > Given that Nice wants to coexist with Java, I don't think there is a a
> > better solution -- Java has null, and a language that cohabits with it
> > must rationalize that (for both meanings of rationalize!).
> >
> > If you don't have that constraint, then the right thing to do is to
> > ensure that you can't write constructors that leave fields un-
> > initialized.
>
> Null can be used beyond "this field is not initialized". It can also be
> useful for representing an optional value. For instance, a function with
> several optional arguments could be defined as:
>
> void foo(String required, ?int opt1 = null, ?String opt2 = null)
> { ... }
>
> One could do this equivalently with overloaded versions of foo, but
> their number grows exponentially with the number of optional arguments,
> so it can become impractical.
What you describe here is still overloading, if not Java
overloading. It is just handled by the compiler in a different way.
OCaml has a similarly feature, and I actually wrote once about the same
null-based implementation. The main reason (Some 2) and 2 do not share
the same representation in ocaml is that the GC is too fast for this
to matter.
You were claiming that an important feature of ?-types is that A is a
subtype of ?A. Have you got examples where this subtping cannot be
replaced by the above kind of overloading?
A potential example would be List<A> < List<?A> for immutable lists,
but I'm not sure you would use that often...
Saying that ?-types are actually no more than cleverly implemented
option types is not a criticism. I think the distinction between A and
?A is useful (even in a Java-like language), and that the tight
integration of ?-types in the compiler considerably improves their
comfort of use. This is what matters. And comfort is not a hack.
---------------------------------------------------------------------------
Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
Ken Rose
> Actually, they are quite nonorthogonal. Vector<3> is different from
> Vector<4> (actually it's a subtype of Vector<4>, a property that would
> have to be inferred from the source code - probably it would be best if
> Vector<N> were defined in terms of Vector<N-1>, that would make the
> inference easy).
What am I missing here...
If you have a record type A with fields a, b, & c, and another record
type B with fields a, b, c, & d, then B is a subtype of A, because
anybody expecting an A will find everything they need in a B.
Why, then, is Vector<4> not a subtype of Vector<3>?
TIA
- ken
Carl G. Alphonce
In article <3F86F6A4...@tfb.com>,
Ken Rose <ken...@tfb.com> writes:
|> Joachim Durchholz wrote:
|>
|> > Actually, they are quite nonorthogonal. Vector<3> is different from
|> > Vector<4> (actually it's a subtype of Vector<4>, a property that would
|> > have to be inferred from the source code - probably it would be best if
|> > Vector<N> were defined in terms of Vector<N-1>, that would make the
|> > inference easy).
|>
|> What am I missing here...
|>
|> If you have a record type A with fields a, b, & c, and another record
|> type B with fields a, b, c, & d, then B is a subtype of A, because
|> anybody expecting an A will find everything they need in a B.
I'm jumping into the middle of the thread, so I apologize if
I'm missing some crucial context. My observation is that structural
similarity is not enough to say that B should be a subtype of A, since
they may be used to model entirely different things. For example,
a temperature can be encoded using a single real quantity, while a
dimension might be encoded as two real quantities, a length and a
width. Would you want to say that a dimension is a subtype of temperature?
Probably not.
|> Why, then, is Vector<4> not a subtype of Vector<3>?
If Vector<N> is defined in terms of Vector<N-1> then perhaps
Vector<N> should be considered a subtype of Vector<N-1>, but otherwise
shouldn't it depend on the context of use?
Again, I haven't followed the thread so I'm not sure how the discussion
got to this point. I just felt like contributing my $0.02's worth
anyway :-)
Carl
Joachim Durchholz
Because I messed it up :-)
Vector<4> should indeed be a subtype of Vector<3>.
Regards,
Jo
Joachim Durchholz
> Ken Rose <ken...@tfb.com> writes:
> |> Joachim Durchholz wrote:
> |> > Actually, they are quite nonorthogonal. Vector<3> is different from
> |> > Vector<4> (actually it's a subtype of Vector<4>, a property that would
> |> > have to be inferred from the source code - probably it would be best if
> |> > Vector<N> were defined in terms of Vector<N-1>, that would make the
> |> > inference easy).
> |>
> |> What am I missing here...
> |>
> |> If you have a record type A with fields a, b, & c, and another record
> |> type B with fields a, b, c, & d, then B is a subtype of A, because
> |> anybody expecting an A will find everything they need in a B.
>
> I'm jumping into the middle of the thread, so I apologize if
> I'm missing some crucial context. My observation is that structural
> similarity is not enough to say that B should be a subtype of A, since
> they may be used to model entirely different things. For example,
> a temperature can be encoded using a single real quantity, while a
> dimension might be encoded as two real quantities, a length and a
> width. Would you want to say that a dimension is a subtype of temperature?
> Probably not.
You are right - but I was talking about the Vector<> types, which have a
well-defined (if somewhat abstract) semantics.
To achieve the type of separation that you want, the language should
have a way to create a new class that's "just like that existing class"
but doesn't have a subtype relationship with it.
As a concrete example, the Location type could be defined in terms of
Vector<Real,3>, but it would not be a subtype of Vector<Real,3>, and
entirely unrelated to Vector<Real,4>.
Regards,
Jo
Franck Arnaud
> > - be non exhaustive, and have a scheme to find
> > the 'nearest' declared implementation for each
> > implicit case.
> > Problem: can you find an algorithm that does not
> > produce incorrect and unexpected matches?
> The developers of Nice, state that they have an algorithm that
> produces correct matches.
I meant "what the programmer expects" ('correct' was not the
best word arguably). Do they have the results of a usability
study?
> Unexpected matches?
In that a programmer reading the code may not be able to
anticipate the behaviour.
> Well if you understand what the lookup does...?
Even single dispatch, which is not itself difficult to understand,
can lead to hard to follow and understand code. Tools that show
how a compiler understands the code help but it's not perfect. A
good programming language should be implementable in programmers'
heads (you should be able to understand the code you read).
> > Adding or removing a declaration for f, or changing the
> > shape of the A or B subtyping trees, may have
> > unexpected effects on unrelated (to the
> > programmer) cases which are then caught by the
> > wrong handler.
> Isn't this to do with OO rather than multiple dispatch?
Yes, it's an extension of the problems of classical
single dispatch inheritance. My feeling is that it's
much worse with multiple rather than single dispatch,
due to the combinatorial explosion. OO-spaghetti on
steroids. A few more features like that and OO may
become as easy to work with as assembly language.
Franck Arnaud
> Concerning methods, multi-methods solve elegantly the
> subclassing-is-not-subtyping dilema. This has been known for a long
> time, but unfornately this knowledge is not widespread.
What is known is that multi methods are _a_ solution to
this problem. That it is an 'elegant', or a good solution,
let alone the best is not known. It is a bit like
overloading (indeed the issues are similar): it is well
known, but whether it is a good idea or not is an open
question, with arguable positions on both sides.
Isaac Gouy
> Isaac Gouy:
>
> > > - be non exhaustive, and have a scheme to find
> > > the 'nearest' declared implementation for each
> > > implicit case.
> > > Problem: can you find an algorithm that does not
> > > produce incorrect and unexpected matches?
> > The developers of Nice, state that they have an algorithm that
> > produces correct matches.
>
> I meant "what the programmer expects" ('correct' was not the
> best word arguably). Do they have the results of a usability
> study?
Is "what the programmer expects" a good yardstick for usability?
Surely that just promotes the familiar.
Maybe "Cognitive Dimensions" will at least provide a systematic way
for future language designers to talk about usability tradeoffs:
http://www.thomas-green.ndtilda.co.uk/workStuff/Papers/AVI2000.PDF
Neelakantan Krishnaswami
> Neelakantan Krishnaswami wrote:
>> Given that Nice wants to coexist with Java, I don't think there is a a
>> better solution -- Java has null, and a language that cohabits with it
>> must rationalize that (for both meanings of rationalize!).
>>
>> If you don't have that constraint, then the right thing to do is to
>> ensure that you can't write constructors that leave fields un-
>> initialized.
>
> Null can be used beyond "this field is not initialized". It can also
> be useful for representing an optional value. For instance, a
> function with several optional arguments could be defined as:
>
> void foo(String required, ?int opt1 = null, ?String opt2 = null)
> { ... }
>
> One could do this equivalently with overloaded versions of foo, but
> their number grows exponentially with the number of optional
> arguments, so it can become impractical.
What if the value you want to optionally pass in is already a type
that includes null? The nice thing about using option types in this
situation is that Option[Foo] and Option[Option[Foo]] are not the same
type, so you can distinguish between "no argument was given" and "null
was the argument".
--
Neel Krishnaswami
ne...@cs.cmu.edu
Franck Arnaud
> Is "what the programmer expects" a good yardstick for usability?
> Surely that just promotes the familiar.
I'll refine my proposition, to "what a programmer can be
taught to expect". With languages that are particularly
bad in that respect, even the language designer can be
caught out by surprising behaviour.
Daniel Bonniot
> overloading. It is just handled by the compiler in a different way.
You mean that a single function with optional parameters is a form of
"overloading"?
> OCaml has a similarly feature, and I actually wrote once about the same
> null-based implementation. The main reason (Some 2) and 2 do not share
> the same representation in ocaml is that the GC is too fast for this
> to matter.
My point was more about readability of the source than about efficiency.
It's still an interesting fact that the representation does not matter
much speed-wise.
> You were claiming that an important feature of ?-types is that A is a
> subtype of ?A. Have you got examples where this subtping cannot be
> replaced by the above kind of overloading?
Sorry, but I am getting confused about what "above" precisely refers
too, as we are speaking about several solutions. Could you clarify this?
However, I can see a way top use overloading to make function call as
convenient as if there was the subtyping. But that involves quite a lot
of tedious work furing function definition.
> Saying that ?-types are actually no more than cleverly implemented
> option types is not a criticism. I think the distinction between A and
> ?A is useful (even in a Java-like language), and that the tight
> integration of ?-types in the compiler considerably improves their
> comfort of use. This is what matters. And comfort is not a hack.
I completely agree with this. I just felt I would stress this comfort
advantage because I did not see it acknowledged in the initial post.
Daniel
Jacques Garrigue
and its use to provide optional arguments in function calls.
Daniel Bonniot <Daniel....@inria.fr> writes:
> > What you describe here is still overloading, if not Java
> > overloading. It is just handled by the compiler in a different way.
>
> You mean that a single function with optional parameters is a form of
> "overloading"?
That, from a type system point of view, a function with optional
parameters can be seen as being virtually overloaded with all its call
patterns. The difference only appears when you think in terms of
compilation, as you have only only one function, the difference in
behaviour being inlined at the call site.
A broader definition of overloading would be: the compiler may
interpret differently a function application according to the types of
the function and the call pattern.
> > OCaml has a similarly feature, and I actually wrote once about the same
> > null-based implementation. The main reason (Some 2) and 2 do not share
> > the same representation in ocaml is that the GC is too fast for this
> > to matter.
>
> My point was more about readability of the source than about efficiency.
> It's still an interesting fact that the representation does not matter
> much speed-wise.
To be exact, this was about representing option types, so we had to
be able to represent things like (Some (Some None)). This incurs a
small cost in the polymorphic case, as you have to process these cases
in a special way. The conclusion was that allocating a block did not
make a significant difference. But I think this would still be valid
even without this extra code.
> > You were claiming that an important feature of ?-types is that A is a
> > subtype of ?A. Have you got examples where this subtping cannot be
> > replaced by the above kind of overloading?
>
> Sorry, but I am getting confused about what "above" precisely refers
> too, as we are speaking about several solutions. Could you clarify this?
Indeed I was mixing with the ocaml implementation (which is very
special kind of overloading).
What I intended to mean is: are there practical cases where it would
not be possible to handle this subtyping by dynamically wrapping a
value in an option type.
For instance
A y;
Option<A> x = y;
could be seen as overloading of "=", and actually mean
A y;
Option<A> x = new Option<A>(y);
but
List<A> y; // supposing List is covariant
List<Option<A>> x = y;
cannot be converted economically.
However I don't see so much need for the second one.
Daniel Bonniot
> A y;
> Option<A> x = y;
> could be seen as overloading of "=", and actually mean
> A y;
> Option<A> x = new Option<A>(y);
> but
> List<A> y; // supposing List is covariant
> List<Option<A>> x = y;
> cannot be converted economically.
> However I don't see so much need for the second one.
Probably this restriction would be more annoying for function types:
have Option<A> -> T as subtype of A->T .
Daniel
Michael N. Christoff
"Donald Roby" <dr...@babsoncourt.com> wrote in message
news:pan.2003.09.30....@babsoncourt.com...
> On Tue, 30 Sep 2003 10:30:17 +0000, Gerry Quinn wrote:
>
> > In article <bl6h8p$o8u$1...@news.oberberg.net>, Joachim Durchholz
> > <joachim....@web.de> wrote:
> >
> >>The second solution goes against programming tradition, and it requires
> >>a bit getting used to. However, omitting all these parentheses and
> >>commas does have an amazing impact on code compactness.
> >
> > Now we just need an explanation of why code compactness is good...
> >
> > Gerry Quinn
>
> Concise and clear code is good.
>
> Compact code can however be extremely unclear.
>
> There are plenty of signatures in comp.lang.perl.misc to prove this point.
>
> Examples can also be done quite effectively in APL.
>
I had a job programming in J when I was about 16. That has to be the most
obfuscated syntax I have ever seen in my life. J, however, was pretty
powerful for technical programming, but I'd hate to have to debug someone
else's code.
l8r, Mike N. Christoff
> And of course, such obfuscation can be done in any language.