4 ms·

The idea is to let users of a language, here CLOS, to be able to intercept meta-messages like instance creation, method call, property access, etc to provide th

The idea is to let users of a language, here CLOS, to be able to intercept meta-messages like instance creation, method call, property access, etc to provide their own implementations. It's like the doesNotUnderstand in SmallTalk, method_missing in Ruby or more recently .Net Dynamic Language Runtime or invokedynamic in Java.

astrange 5y ago
It's commonly used in Objective-C due to Smalltalkness - NSInvocation, XPC, OCMock, etc.
nerdponx 5y ago
I believe Lua has this with metatables, and of course Python has its "magic methods" and metaclasses.
DaiPlusPlus 5y ago
That’s a bad idea though, and the past 30+ years of OOP has laid-bare all of the problems associated with not having compile-time object type safety. Just because you can do something doesn’t mean you should… Outside of prototyping and quick-hacks, there is no legitimate reason to use `dynamic` in C#/.NET: instead, the moment your program receives or handles a “late-bound” (i.e. untyped) object your program should verify its actual type and then access it only through a wrapper type (be it an interface, struct, or class) which is how you can enforce guarantees about that object. This also applies to reflection (so have all of your `GetMethod` calls during the wrapper’s ctor and use Action/Func wrappers over MethodInfo).
- db48x 5y ago
  It’s nothing like reflection or untyped objects.
  - DaiPlusPlus 5y ago
    I was referring to this: > It's like the [...] .NET Dynamic Language Runtime or invokedynamic in Java. My answer concerns the "DLR", aka `dynamic` type in C#/.NET, which is untyped. The GP is not correct when describing the DLR/`dynamic` as to "be able to intercept meta-messages like instance creation, method call, property access, etc to provide their own"... ...C#/.NET does not allow for this: you cannot intercept methods or otherwise have Smalltalk-style message-passing in .NET. Using `dyanmic` does allow you to intercept methods and define behaviour but only with `dynamic` objects managed by your own `IDynamicMetaObjectProvider`, which I concede you could use to implement this, but that would force you to type everything as `dynamic` which also means you lose static type safety. (pre-.NET Core, the CLR had hardcoded magic behaviour for `Proxy` types, which is how .NET Remoting worked with any object type: including sealed types, but this was removed in .NET Core and its replacement in `DispatchProxy` falls far short: it only works with interfaces (hence vtables), not static/non-virtual methods). -------------- What surprises me about .NET's CLR is that despite the (frustrating) simplicity of its type-system, that applications still don't have any real opportunities to extend the CLR's type-system to suit themselves. This includes anonymous refinement types via flow-analysis (TypeScript gets this right), the lack of support for real ADTs (F#'s tagged-unions exist in their own hierarchy: you can't have a tagged-union of arbitrary types, which basically makes them the same as Java's `enum` classes).
- Blackthorn 5y ago
  > That’s a bad idea though Sure, it's usually a bad idea to muck around with the MOP or use metaclasses in Python or whatnot. But every once in a while it really is the best solution to the problem, so you're glad you can do it at all.
- travisgriggs 5y ago
  > That’s a bad idea though, and the past 30+ years of OOP has laid-bare all of the problems associated with not having compile-time object type safety Hyperbole much? The past 30 years has shown me that a language with a joke of a compile type system system continues to be The Language to write operating systems that still rule the world and run most of the chips we use in every day life: C. Until recently, Linux built in said crappy type system was glued together with completely unchecked shell scripts. The great and abominable typless wonder that rules and glues mankind to the internet is JavaScript. Visual Basic dominated the “business scripting” world. The language that reins in scientific computing, is typeless Python. The language that participated in Apples comeback with a fraction of the manpower being spent elsewhere: ObjectiveC. I write a lot of Swift and Kotlin. I have as many bugs as I did when I wrote Objective C. The thing I have learned with types is that it’s an 80/20 thing. I’m not an anti-typer. I don’t believe in relying on any one single paradigm to improve the quality and robustness of my systems. Do tests help? Yes. Can some level of type annotation/checking be good? Yes. But taken to an extreme, for me they follow the axiom: “Every institution perishes due to an excess of its own first principle.” Maybe tooling is finally getting there. And we’ll finally transition to a more compile time safe world. What I have observed though is that when any system/language becomes too rigid/constrained, people will swing to more @dangerous” solutions to have the freedom to create what they want. Even between program this occurs. Numerous inter program formats and schemas have come and gone. What dominates today? JSON. > Just because you can do a thing doesn’t mean you should… Just because you don’t appreciate a thing, doesn’t mean others shouldn’t do it.
- pjmlp 5y ago
  dynamic was introduced in .NET due to COM, and given Windows team love for COM, there are plenty of reasons to still use it. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic#com-interop https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
pjmlp 5y ago
Smalltalk also has metaclasses, that is where class methods live and the whole code manipulation. myMeta := self class.

astrange 5y ago

It's commonly used in Objective-C due to Smalltalkness - NSInvocation, XPC, OCMock, etc.

nerdponx 5y ago

I believe Lua has this with metatables, and of course Python has its "magic methods" and metaclasses.

DaiPlusPlus 5y ago

That’s a bad idea though, and the past 30+ years of OOP has laid-bare all of the problems associated with not having compile-time object type safety. Just because you can do something doesn’t mean you should… Outside of prototyping and quick-hacks, there is no legitimate reason to use `dynamic` in C#/.NET: instead, the moment your program receives or handles a “late-bound” (i.e. untyped) object your program should verify its actual type and then access it only through a wrapper type (be it an interface, struct, or class) which is how you can enforce guarantees about that object. This also applies to reflection (so have all of your `GetMethod` calls during the wrapper’s ctor and use Action/Func wrappers over MethodInfo).

db48x 5y ago
It’s nothing like reflection or untyped objects.
- DaiPlusPlus 5y ago
  I was referring to this: > It's like the [...] .NET Dynamic Language Runtime or invokedynamic in Java. My answer concerns the "DLR", aka `dynamic` type in C#/.NET, which is untyped. The GP is not correct when describing the DLR/`dynamic` as to "be able to intercept meta-messages like instance creation, method call, property access, etc to provide their own"... ...C#/.NET does not allow for this: you cannot intercept methods or otherwise have Smalltalk-style message-passing in .NET. Using `dyanmic` does allow you to intercept methods and define behaviour but only with `dynamic` objects managed by your own `IDynamicMetaObjectProvider`, which I concede you could use to implement this, but that would force you to type everything as `dynamic` which also means you lose static type safety. (pre-.NET Core, the CLR had hardcoded magic behaviour for `Proxy` types, which is how .NET Remoting worked with any object type: including sealed types, but this was removed in .NET Core and its replacement in `DispatchProxy` falls far short: it only works with interfaces (hence vtables), not static/non-virtual methods). -------------- What surprises me about .NET's CLR is that despite the (frustrating) simplicity of its type-system, that applications still don't have any real opportunities to extend the CLR's type-system to suit themselves. This includes anonymous refinement types via flow-analysis (TypeScript gets this right), the lack of support for real ADTs (F#'s tagged-unions exist in their own hierarchy: you can't have a tagged-union of arbitrary types, which basically makes them the same as Java's `enum` classes).
Blackthorn 5y ago
> That’s a bad idea though Sure, it's usually a bad idea to muck around with the MOP or use metaclasses in Python or whatnot. But every once in a while it really is the best solution to the problem, so you're glad you can do it at all.
travisgriggs 5y ago
> That’s a bad idea though, and the past 30+ years of OOP has laid-bare all of the problems associated with not having compile-time object type safety Hyperbole much? The past 30 years has shown me that a language with a joke of a compile type system system continues to be The Language to write operating systems that still rule the world and run most of the chips we use in every day life: C. Until recently, Linux built in said crappy type system was glued together with completely unchecked shell scripts. The great and abominable typless wonder that rules and glues mankind to the internet is JavaScript. Visual Basic dominated the “business scripting” world. The language that reins in scientific computing, is typeless Python. The language that participated in Apples comeback with a fraction of the manpower being spent elsewhere: ObjectiveC. I write a lot of Swift and Kotlin. I have as many bugs as I did when I wrote Objective C. The thing I have learned with types is that it’s an 80/20 thing. I’m not an anti-typer. I don’t believe in relying on any one single paradigm to improve the quality and robustness of my systems. Do tests help? Yes. Can some level of type annotation/checking be good? Yes. But taken to an extreme, for me they follow the axiom: “Every institution perishes due to an excess of its own first principle.” Maybe tooling is finally getting there. And we’ll finally transition to a more compile time safe world. What I have observed though is that when any system/language becomes too rigid/constrained, people will swing to more @dangerous” solutions to have the freedom to create what they want. Even between program this occurs. Numerous inter program formats and schemas have come and gone. What dominates today? JSON. > Just because you can do a thing doesn’t mean you should… Just because you don’t appreciate a thing, doesn’t mean others shouldn’t do it.
pjmlp 5y ago
dynamic was introduced in .NET due to COM, and given Windows team love for COM, there are plenty of reasons to still use it. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic#com-interop https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

pjmlp 5y ago

Smalltalk also has metaclasses, that is where class methods live and the whole code manipulation. myMeta := self class.