> Since I’m considering taking the leap I thought I solicit people’s opinion and see > who’s using the object approach and what do/don’t you like about it.
<ramble> It depends. By the way, this is a question that goes back in programming *way* before 4D even existing, so don't expect there to ever be a definitive answer. Well, there are plenty of definitive answers, but they aren't all the same ;-) Kind of a style issue and judgement style, but a few observations: * I hope people don't go back and rewrite a ton of code needlessly for a new language feature. If the modification pays for itself and you need to write anyway, sure. But it's not always better. Opaque/abstracted is harder to read/can be more flexible. Costs and benefits. * Try out JSON arguments. There are times when they are absolutely a better approach. Every place, all of the time? No. It's worth digging in yourself and feeling through the pros and cons. Then you've got another tool in the back when you need it. * Long parameter lists are pretty unworkable. They're hard to read and hard to type. * Huge JSON manifests are also unworkable, but not as quickly. For anyone that's worked with JavaScript much, you'll find it's common to have to manipulate really huge, complicated JSON blocks to pass as a parameter. It's kind of horrible, frankly. Particularly since JavaScript offers some really nice alternatives. (Make a closure & expose internal properties as methods. That lets your property setters automatically run in response to data modifications/initializations. Make a lot more sense in an asynchronous environment, improves the quality of introspection, supports better data hiding, etc., etc.) * Yeah, what Doug said about code generators: Code Generators Rule! * Yeah, exposing simple types to the compiler is really helpful in 4D and I've long relied on this. I'm kind of throwing in the towel now, though. It's very much a tail-wags-dog approach. The 4D compiler is great to have but, ultimately, it's pretty feeble. It has zero support for inspecting an object and sorting out if the object satisfies the rules for a custom type. So, no support for object/structs. Sure C_OBJECT exists and has merits, but it doesn't improve 4D's concept of type. We can't add new types in 4D and it's a giant liability. C_OBJECT makes a native feature that we've had available by other means for, what, nearly 30 years? That's good, but only as far as it goes. Speaking of custom types, you can (and kind of have to) write your own type validator for manifest-driven arguments. (I call JSON data collections passed as a set of processing details a manifest. Why? Well, it's a name that doesn't carry a lot of baggage and kind of covers what it does. Other, better names probably exist.) Tedious but necessary, if you like to pre-check your code. And, unfortunately, this only works if you have a test harness in good order and/or at runtime. I want to catch errors as earlier, namely at compile time. Not in 4D. * I mentioned that parameter passing is an old topic, and it is. The Structured Programming movement (one of the earliest attempts to straighten out the spaghetti in the bowl) deals with little else. Well, parameter passing and method decomposition & arrangement. They came up with a bunch of prescriptions, many of which sound quaint or completely bizarre now. Still, they made some good points. One at least can't be denied: When you hide a bunch of different values in a bundle, the code isn't nearly as readable. I mean that you literally can't read the code. Compare: Window_New(settings) Window_New(Edit Record;Upper Left +20;Upper Left + 400;Top+300;Top+60) In practice, it's easy to improve the one-line version by including assignments then and there that expose the settings. (Something you see pretty well universally in other languages.) There's a bit of a risk with the stuff-in-a-settings block approach, though....it's easy to make some really sloppy code. Just keep stuffing stuff into the manifest and ship it off to your updated method. Yeah, well, sometimes that's good...sometimes you're making a bloated method that would be better off being decomposed. Maybe you're missing the opportunity for a *better* data structure. There's a reason refactoring is kind of thing...it needs to be. Speaking of which, one of Martin Fowler's original refactoring patterns is to root out "garbage barge" classes. I've always loved that term. Unless it's not clear, I'm just rambling around here ;-) Seriously, there isn't one magic way of doing things right. If you find a strategy that you can use effectively, that's awesome. Do that. Just don't think it's magic. Or if it is magic, it's probably you more than anything else. Speaking in wide generalities: * Keep you data structures as clear and clean as possible. * Think about the next programmer! * Sometimes more abstraction is good, but it makes everything harder to follow. I used to go about one level of abstraction further than I could follow. Now I tend to go about one less. See previous point. On another note, one thing I like about JSON block arguments is that they're super easy to log. That's kind of great. </ramble> ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
