addressalign-toparrow-leftarrow-leftarrow-right-10x10arrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblinklocation-pinlockm-swarmSearchmailmediummessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahooyoutube

A further analysis of Hack documentation and feature list

From: Russell
Sent on: Tuesday, April 8, 2014 3:13 PM

I've taken a little time to go through more of the Hack language documentation and look at its feature list. There are a few feature ideas that could be useful in design sense but most of the listed features exist primarily to support static typing (more verbosity) or are ones that PHP already has but are renamed, slightly tweaked, or customized to fit their version of static typing.

Type Annotations: Static typing, in other words.

Generics: Object/Value containers to support static typing.

Nullable: They actually discourage using this as it makes life worse in a static typed world because it's very close to just using 'mixed'.

Collections: These are just standard classes fit to handle specific data types or custom versions of Iterators. These don't appear to be any different than creating a custom class to do the same thing (except their version is 'final' so you can't extend them even if you wanted to), importing an existing library for data types, or using the built-in SPL Data Structures or SPL / Built-In Interfaces to create similar items. Yes, there is advantage to having some of these as standard libraries but it shouldn't require switching to a new language to important a common library of data classes.

Shapes: A custom way of making classes with typed public properties. It's no more or less verbose than just creating a class definition directly. It would still be recommended good practice to put one shape per file and to spread it out across lines for ease of readability so ultimately it's syntactic sugar and added complexity.

Type Aliasing: A good way to confuse yourself (having multiple things which are essentially the same thing but you wouldn't know that until you look carefully at the definition), your fellow developers, or prevent yourself from doing basic operations because it's not typed correctly. It adds a lot of complexity and the use-case of preventing minutes from being passed into a seconds operation is ... restrictive and unlikely.

Continuations: They're Generators from PHP 5.5.

Traits: They're Traits from PHP 5.4, but with special rules for static typing.

Lambda Expressions: They're Anonymous Functions / Closures without the surrounding function() { } enclosure and implicit merging of scope variables with variable-by-value. This is one of the few places where verbosity is decreased but it does so at the decrease of readability as well. It encourages more complexity in a smaller area and the use-case is actually very small without becoming too complex. (Reading the 'Why ==>?' page is somewhat amusing, though increases my feeling the entire thing is a big joke)

Tuples: Immutable arrays. With a lot of 'gotcha!' caveats. Translation: We don't trust you so we're going to shoot ourselves in the foot to make sure you can't also shoot our foot. As soon as you find you do need to modify an array you have to go back and change it.

Override Attribute: Good for declaring you need your parents' implementation of the same method in static code analysis. Otherwise just extra maintenance or reduced flexibility (especially in their primary example).

Method Dispatch: Another word for PHP's Strict Mode reporting. Plus a little extra error reporting so you don't have as much flexibility.

Constructor Argument Promotion: Seems reasonable. I see potential conflicts if the variable is declared or special logic needs to be done before setting, but overall reasonable.

Union Types: (lack of support) In their effort to support static typing they've made the usage of classes which have both interfaces and extensions more verbose. You have to declare a new variable containing the same object then explicitly check if it's an instance of the interface before calling a method that exists on the interface.

The rest of the documentation seems about on par with the above. A few good things, some reasonable things, and lots of questionable things.

 

The biggest impression I got while reading through the documentation is that this project was a Computer Science graduate wet dream to bring "real programming" to PHP. It sounds good in theory and maybe even on paper, especially since so many other languages already have these, but adds very little actual value for experienced or mindful developers. The primary purpose it seems to serve is a safety net for bad programming, poor design, or hand-wavey 'looks like code to me' reviews.

*shrugs*

Personally I don't like it because it would get in my way a lot more than it would help. It focuses too much on the nitty-gritty details (which are important, just not this much) rather than the bigger picture.

- Russell

 

 

People in this
group are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy