Reputation
Next privilege 200 Rep.
See reduced ads
Badges
6
Newest
 Commentator
Impact
~873 people reached

  • 0 posts edited
  • 0 helpful flags
  • 4 votes cast
Feb
26
comment Changing method signature for implementing classes in PHP
@user61852 I'm not saying this to defend PHP (believe me) but, but most languages would not let you change an inherited method-signature - historically, this was possible in PHP, but for various reasons decided to (artificially) restrict programmers from doing this, as it causes fundamental problems with the language; this change was made to bring the language more in line with other languages, so I'm not sure which language you're comparing to. The pattern demonstrated in the second part of my answer is applicable and useful in other languages like C# or Java as well.
Aug
3
comment does this model-pattern have a name?
I received the following answer from Martin Fowler: "I’ve seen various things like it. The operational/knowledge layer distinction in my Analysis Pattern book is about this. Various people wrote up something like this under the name “Type Object” (an example is ksc.com/article3.htm, but I’m sure there’s more to dig out.) I remember something in Peter Coad’s work too. I bet there’s others, although I haven’t dug around in this territory for a while." - it looks like the "type object pattern" is more of an OOP generalization of the "data descriptor" pattern?
Aug
3
comment does this model-pattern have a name?
Very good, but I still don't see anything describing the idea of mirroring property-names 1:1 in the descriptor? Fundamentally I agree, this is a data-descriptor, but it's a little more than that - mirroring the property-names enables a kind of "cross reflection" going either from a property in a descriptor to an object property value, or vice-versa. I don't guess that makes it a new pattern though, just an extension to an existing pattern. Should I mark this as the correct answer?
Jul
23
comment does this model-pattern have a name?
@Alex I agree that data-driven programming (and model-driven architecture) is an approach, not a pattern. It still seems like I'm following a pattern though, I mean just at the low level, of every model-type having a meta-type with the same shape - the consumption of that meta-data by helpers and services is an approach, but it seems like following the implementation pattern is what makes that approach practical. Maybe that doesn't make it a pattern, but then I'm not sure what does. (?)
Jul
21
comment does this model-pattern have a name?
@Alex because it's not just data - if it were, you could just as well embed it as annotations and use reflection. So perhaps more accurately "metadata-types", which I guess I just kinda shortened to "meta-types". The bigger question is, is this a known pattern? If it is, it can't be very common - I have never seen it mentioned or described anywhere, and I find that suprising, given how well this actually works in practice.
Jul
16
comment does this model-pattern have a name?
Other terms I've used at times: "co-typing" or "meta-types". I like "type descriptor" best, it bugs me that it refers to a C# language feature, because it accurately describes what this other type is for. Do you know if "type descriptor" means anything in programming in general, or is it just something MS came up with for C#?
Jul
16
comment does this model-pattern have a name?
"Statically-typed Reflection", interesting - except, this isn't reflection, since there is no information derived from the type itself, not even the type-name is used... getType() isn't a factory method, I think the factory-method is UserType::instance()? As for how this compares to working with reflection/annotations in C# - I like this much better, it feels more like "programming" and less like "hacking", since you're leveraging ordinary OO language features and common OOP patterns; reflection/annotations always felt a bit like raping the source code to me ;-)
Oct
21
comment Differences between TypeScript and Dart
For the record, this works var x = {}; x['foo'] = 5; and this does too var y:any = {}; y.foo = 5;, but I was a little surprised to find you're right about this - the perceived type of {} is {} rather than any. Could be a type inference issue. I posted the issue here - we'll see how they respond.
May
9
comment What is the difference between functional relational programming and functional programming?
PS: thank you @axblount, this is an absolutely beautiful answer!
May
9
comment What is the difference between functional relational programming and functional programming?
One very interesting language to take a look at is Opa - a functional language that offers mutable state bound to (relational or document) database-records, very direct query-syntax and an extremely powerful type-system. It's not a functional-relational language per se, but it might be a suitable language in which to exercise the idea of functional-relational programming. (don't be fooled by how this is branded as a "JavaScript framework" - it is a compiled and unique language unlike anything else I've seen.)