My 2c.... Its important to stay at a high level for this. The key is do
you want a language that expresses how to do something vs what result i
want which can be more succinct.
Objects : Pro: Easy to move from existing system languages
Encapsulated fields is important for mutable
fields..it may be to easy for other objects and possibly threads to modify
them. (You had the same thinking with capsules ). That said with
interfaces it would not be neccessary.
Its a means of organization .. I dont like how
data is seperately declared in Haskel though this can be handled by
convention.
Cons: Not really needed .
Interfaces: Writing libs . However there is existential types . This to
me looks very similar to interfaces:
class Shape_ a where
perimeter :: a -> Double
area :: a -> Double
data Shape = forall a. Shape_ a => Shape a
type Radius = Double
type Side = Double
data Circle = Circle Radius
data Rectangle = Rectangle Side Side
data Square = Square Side
instance Shape_ Circle where
perimeter (Circle r) = 2 * pi * r
area (Circle r) = pi * r * r
instance Shape_ Rectangle where
perimeter (Rectangle x y) = 2*(x + y)
area (Rectangle x y) = x * y
instance Shape_ Square where
perimeter (Square s) = 4*s
area (Square s) = s*s
instance Shape_ Shape where
perimeter (Shape shape) = perimeter shape
area (Shape shape) = area shape
circle :: Radius -> Shape
circle r = Shape (Circle r)
rectangle :: Side -> Side -> Shape
rectangle x y = Shape (Rectangle x y)
square :: Side -> Shape
square s = Shape (Square s)
shapes :: [Shape]
shapes = [circle 2.4, rectangle 3.1 4.4, square 2.1]
The question is why do Haskel libs avoid such constructs (some Haskell
people think this is an anti pattern)... i would have thought passing
around a more abstract representation is better. .. The above could be
sugared to provide something that looks like inheritance/ interfaces for
easy porting but would not constrain newer libs.
Inheritance: Easy to move from existing system languages. As discussed
previously im a firm believer in extention by composition and constructor
injection of common work , its slightly more work but its far easier to
maintain.
Type Classes: Im not an expert but people who use them speak very
favourable of them and prefer Haskel /Skala etc. The idea of expressing the
intent leeds to more succinct and better code. I have some concern whether
your average programmer will feel the same way, they tend to avoid generics
in C# except for around collections and i feel the same will happen but it
depends on what the standard lib will look like . Also their use in Rust
libs so far have been low , this will change but the C/C++ people writing
extentions or porting tend to write c like modules ( traits are newish and
the standard lib uses more concepts obv eg str but its worth watching how
it develops) .
Another possibility is extend C# generics with more extensive predicate
like constraints as per the new C++ Concept lite proposal
https://docs.google.com/a/isocpp.org/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATQBaXNvY3BwLm9yZwF2Mg
Ben
On Mon, Oct 28, 2013 at 12:44 AM, Jonathan S. Shapiro <[email protected]>wrote:
> If the BitC work goes forward, one of the key decisions is whether to
> admit single inheritance into the language. There are a lot of pros and a
> lot of cons.
>
> Originally, I chose to go procedural. This was partly because of the
> EROS/Coyotos experience. EROS was done in C++. The overheads were high. The
> complexity was high. Ultimately we had to compile with a lot of language
> features turned off, so it wasn't C++ anymore. It wasn't a good fit, since
> we (intentionally) didn't want inheritance or exceptions. So in Coyotos I
> switched back to C. The problem with C was that I really wanted a language
> with specified semantics. Thus BitC.
>
> So we beavered away on BitC, and the time came to start writing the
> standard library. And for *that* problem there sure seem to be a lot of
> cases where Interfaces (as opposed to TC instances) seem like a good match.
> And at least a few places where (single) inheritance seems like a really
> useful thing. Perhaps I let myself be discouraged too much by the problem
> with by-ref types not having been first class, and it all would have come
> out fine.
>
> But if we're going to re-open this language, I think we need to come to a
> resolution on this. And I think it needs to have two parts: (1) a
> comparative discussion of interfaces and TC instances, and (2) a discussion
> of pros and cons for admitting objects.
>
>
> shap
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
