Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, they got some intern who was completely unfamiliar with the old library to just write a new one from scratch without looking at what already existed.

It's 2010, and we're still innovating on how you pass color components around. Seriously?

Actually, in the first example, the MacOS code looks like the API designed by clueless interns that don't get OO. It's the same classic mistake of passing in an X and a Y instead of a Point Object from the 1st generation Java GUI library. The iPhone code does the right thing. Instead of passing around un-encapsulated data, pass around Objects instead!



Poor as it is, I think the original intention of the Mac version was to avoid buffer overflows. You can potentially screw up with the iPhone code by doing:

    const CGFloat *rgba = CGColorGetComponents([fg CGColor]);
    CGFloat a = rgba[4]; //Crash!
However, you do have a point in that explicit data structs are better than implicit ones. I would have chosen this API:

    typedef struct {
        CGFloat r;
        CGFloat g;
        CGFloat b;
        CGFloat a;
    } UIRGBAColor;
    
    //...
    
    UIRGBAColor rgba = [fg rgbaComponents];


that's bullshit. why is the right thing to encapsulate your data into an object before passing it around? that's your opinion on what's right, I guess, but I don't think it's the right way.


I suppose for some idiosyncratic value of "right."

In the Point example, the API that respects encapsulation would remain the same between the 2D and 3D versions, along with any code using it. The API with un-encapsulated data would have to change at every single place in the code where a Point was passed.

(In other words, the implementation details of Point have leaked out into the system at perhaps 100's of places. Avoiding this and decoupleing ourselves from implementation is precisely why we have encapsulation in OO.)

How this applies to color is left as an exercise to the student.


How this applies to color is left as an exercise to the student.

This is what I'd like to hear. Cocoa has NSPoint, which is exactly what you're talking about, for points. And NSColor is already a kind of the basic object for colors. Do you really need more primitive types for this?


What object would you pass to NSColor to generate a color from HSB components? Wrap them to NSHue, NSSaturation, and NSBrightness? Or generate NSHueParameters first?

(Please note that I don't intend to argue, I'm asking for a better solution. Thanks!)


I think he's referring to the API to get the components out of the NS/UIColor, not create the NS/UIColor object.


There are individual methods like `hueComponent` if you want them. http://developer.apple.com/mac/library/documentation/cocoa/r...

I still don't get the point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: