-1

How haskell types are different than regular PHP classes.

If i disable extending can I simulate something similar in PHP or JavaScript.

Haskell:

data Person = Person { firstName :: String  
                      , lastName :: String  
                      , age :: Int  
                      , height :: Float  
                      , phoneNumber :: String  
                      , flavor :: String 
age :: Person -> Int  
age (Person p) = p.age  

newAge = age(Person {age:=35})

Js:

class Person {
    constructor(data) {
        this.data = data
    }
}
function age(p) {
   if (p instanceof Person) return p.age
}
let personAge = age(new Person({age: 35})); // 35

There can be syntax errors but ignore them.

In a nutshell if I dont use inheritance the js code is similar to Haskell's.

I dont have pattern matching but i can use "if instanceof " to check types.

AJF
  • 11,767
  • 2
  • 37
  • 64
  • 4
    This is not a typeclass... But a `data`type. Datatypes act like records. One of the crucial differences is still that data is immutable in Haskell. A typeclass in Haskell is usually closer to what is known in OO programming as an *interface*. – Willem Van Onsem Apr 23 '18 at 14:31
  • 2
    It seems there are two different questions here. The title asks about typeclasses whereas the question asks about datatypes. Those are two *very* different concepts in Haskell, so which are you asking about? – Silvio Mayolo Apr 23 '18 at 14:35
  • 2
    Your Haskell code is incorrect anyway. `age` is predefined by the record syntax, and `p = Person "bob" "smith" 34 1.7 "123-4567" "?"; newage = age (p { age = 35} )` would be closer to the mark. – chepner Apr 23 '18 at 14:44
  • If you remove PHP inheritance, Haskell's parametric types, PHP mutability, Haskell's multiple constructors and pattern matching, PHP methods, Haskell's higher kinds, etc. etc. eventually you get something similarly trivial, but perhaps it's not that interesting. – chi Apr 23 '18 at 14:52

1 Answers1

4

Besides the confusion between type classes and data types, you may want to read OOP vs. Haskell type classes. Data types, which you use, behave much like immutable objects. So Haskell's

data Person = Person { age :: Int }

p1, p2 :: Person
p1 = Person { age = 35 }
p2 = p1 { age = age p1 + 1 }

might be written in ES6 like

class Person {
    constructor(age) {
        this.age = age;
    }
}

p1 = new Person(35);
p2 = new Person(p1.age + 1);

In ES6 this does not guarantee against immutability, though. For that, see the const and ... keywords for merging the properties of objects without changing the original objects. The article discusses various other solutions but ends up suggesting:

const p1 = {
    age: 35
}

const p2 = {
    ...p1,
    age: p1.age + 1
}
sshine
  • 15,635
  • 1
  • 41
  • 66
  • Thanks, but can i ask in haskell if i have age for data Person and Manager for example: age (Person p) = p.age age (Manager m) = m.managerAge Doesnt this break Open Closed principle? –  Apr 23 '18 at 14:57
  • 2
    In versions of Haskell that allow duplicate field names, the function really takes *two* arguments, a type and a value of that type. With the appropriate extension, you can add the type argument explicitly: `age @Person p` instead of `age p` (which infers the correct "version" of `age` from the argument `p`). – chepner Apr 23 '18 at 15:02
  • @user2693928: What's a Manager? This sounds like you're mixing object-oriented inheritance into Haskell data types. The Open/Closed Principle mostly applies to OOP. If you'd like to know how it applies to functional programming, I think you should ask a new question. See [SOLID for functional programming](https://stackoverflow.com/questions/5577054/solid-for-functional-programming), [Object-oriented Design Patterns From a Functional Perspective](http://gorodinski.com/blog/2013/09/18/oop-patterns-from-a-functional-perspective/), etc. – sshine Apr 23 '18 at 15:07
  • I have different type of form fields: TextField, PasswordField, etc. How can i add new field type like (AutocompleterField) without breaking Open closed principle. I want new fields to be pluggable. All code for different field to be in a separate file instead of defining all different implementations in one place. –  Apr 23 '18 at 15:11
  • @user2693928 It seems to me that you're trying to directly apply OO principles in Haskell. While this is ostensibly doable, it will result in unidiomatic and, frankly ugly, Haskell code. You'd do better to learn the functional idioms used in Haskell and rethink your design using those principles. – Silvio Mayolo Apr 23 '18 at 15:25
  • Haskell data types can allow several constructors, similarly to variant types in some other languages. A type `data T = A Int | B String` has no int fields, and has no string fields. It could be modeled in OOP through inheritance from an empty base class and abusing `instanceof` -- or better, through the visitor pattern (which can model any algebraic data type). – chi Apr 23 '18 at 15:30
  • Stackoverflow works best if you contain questions. If they keep expanding, then both comments and continually changing your questions are terrible ways to have a longer discussion. – sshine Apr 23 '18 at 15:45