5 ms·

You can generate fieleds of ORM objects based on the values returned by a query. If you're writing a game, you can represent in-game objects directly with langu

by gambler 14y ago

You can generate fieleds of ORM objects based on the values returned by a query. If you're writing a game, you can represent in-game objects directly with language objects and add more properties and methods when they're modified. In short, you can cut down on abstraction layers when working with behaviors that are inherently runtime.

ajanuary 14y ago
It's perfectly possible to have a dynamic type system with closed objects (can't add properties). Then again it's not really possible to have a static type system with open objects (at least, I can't think how you would).
- kd0amg 14y ago
  There exist type systems that can handle "strong" (i.e. type-changing) updates, but the ones I know of will only permit it for unique (linear/affine) references. You might be able to take advantage of the guarantee that properties are not being removed, so the update just turns the object into a subtype of what it once was. Then other pieces of code with reference to that object can continue on type-safely, but they won't be able to use those new properties without somehow being informed about them (statically).
tedunangst 14y ago
Just use a dictionary or hashtable.
- icebraining 14y ago
  But then, what have you really gained? A more cumbersome syntax? Because that's still unverifiable by the compiler.
  - tedunangst 14y ago
    That's kind of my point.
- qznc 14y ago
  ... of which type? Map<String,Object>? Then you have to use casts to convert Object to Integer for example. If static typing would be good enough, you would not need casts. A cast basically says: "Hey compiler forget about type checking, just believe me that this thing has that type."
  - tedunangst 14y ago
    Dynamic typing basically says "Hey compiler forget about type checking, just believe me that this thing has that type."
    - qznc 14y ago
      A dynamically typed language can still be strongly typed. For example, Python will give you an exception on a type error, where C/C++ could wreck havoc in your memory.
      - tedunangst 14y ago
        Use dynamic_cast. Or java. Or c#.
- gambler 14y ago
  A hashtable doesn't have methods. In a dynamically typed language, I can generate object methods based on the data currently available in the database (either columns or even row content) and take advantage of all the language's syntactic features while doing that. In respect to any language, the database is inherently dynamic, because it doesn't share your type system and the schema can be redefined at any point after compilation of your code. A statically typed language doesn't magically change that. The best you can do is to write some classes in advance and then hope nothing gets out of sync. So, to put it in simpler terms, some things are inherently dynamic, and dynamic languages make working with them easier.
danieldk 14y ago
You could do the same in a statically typed language using algebraic data types or using inheritance and introspection. (I am assuming that the types of values returned by a query are finite and known.)
- riffraff 14y ago
  isn't introspection exactly one of things that are _really hard_ to do in a type safe manner ?
colanderman 14y ago
cough LINQ [1] cough cough Ur/Web [2] cough Both these languages have strongly-typed queries. Database queries are not "inherently runtime". If you don't know what type of data is stored in your database, your code is probably incorrect. [1] http://en.wikipedia.org/wiki/Language_Integrated_Query http://en.wikipedia.org/wiki/Language_Integrated_Query [2] http://www.impredicative.com/ur/ http://www.impredicative.com/ur/
- icebraining 14y ago
  "Strongly typed" != "Statically typed"
- gambler 14y ago
  The part of LINQ you refer to works by running a code generator against database schema before writing any code. In other words, it is not a language feature (you can generate code in any language), it is highly complex and it is a maintenance liability. Generally, any kind of code generation is a crutch. Ability to dynamically modify objects removes the need for it. The way to go in .NET is the opposite direction: Entity Framework with Code First approach.
Dn_Ab 14y ago
F# Type providers are a powerful solution to problems of the same class as your first example. http://research.microsoft.com/pubs/173076/information-rich-themes-v4.pdf http://research.microsoft.com/pubs/173076/information-rich-t... And smart use of data structures, algebraic types and composition for the latter. The benefit of this is you build a sort of theory for your game, sometimes it predicts and suggests things that would not have been obvious to you otherwise.

by gambler 14y ago

ajanuary 14y ago

It's perfectly possible to have a dynamic type system with closed objects (can't add properties). Then again it's not really possible to have a static type system with open objects (at least, I can't think how you would).

kd0amg 14y ago
There exist type systems that can handle "strong" (i.e. type-changing) updates, but the ones I know of will only permit it for unique (linear/affine) references. You might be able to take advantage of the guarantee that properties are not being removed, so the update just turns the object into a subtype of what it once was. Then other pieces of code with reference to that object can continue on type-safely, but they won't be able to use those new properties without somehow being informed about them (statically).

tedunangst 14y ago

Just use a dictionary or hashtable.

icebraining 14y ago
But then, what have you really gained? A more cumbersome syntax? Because that's still unverifiable by the compiler.
- tedunangst 14y ago
  That's kind of my point.
qznc 14y ago
... of which type? Map<String,Object>? Then you have to use casts to convert Object to Integer for example. If static typing would be good enough, you would not need casts. A cast basically says: "Hey compiler forget about type checking, just believe me that this thing has that type."
- tedunangst 14y ago
  Dynamic typing basically says "Hey compiler forget about type checking, just believe me that this thing has that type."
  - qznc 14y ago
    A dynamically typed language can still be strongly typed. For example, Python will give you an exception on a type error, where C/C++ could wreck havoc in your memory.
    - tedunangst 14y ago
      Use dynamic_cast. Or java. Or c#.
gambler 14y ago
A hashtable doesn't have methods. In a dynamically typed language, I can generate object methods based on the data currently available in the database (either columns or even row content) and take advantage of all the language's syntactic features while doing that. In respect to any language, the database is inherently dynamic, because it doesn't share your type system and the schema can be redefined at any point after compilation of your code. A statically typed language doesn't magically change that. The best you can do is to write some classes in advance and then hope nothing gets out of sync. So, to put it in simpler terms, some things are inherently dynamic, and dynamic languages make working with them easier.

danieldk 14y ago

You could do the same in a statically typed language using algebraic data types or using inheritance and introspection. (I am assuming that the types of values returned by a query are finite and known.)

riffraff 14y ago
isn't introspection exactly one of things that are _really hard_ to do in a type safe manner ?

colanderman 14y ago

cough LINQ [1] cough cough Ur/Web [2] cough Both these languages have strongly-typed queries. Database queries are not "inherently runtime". If you don't know what type of data is stored in your database, your code is probably incorrect. [1] http://en.wikipedia.org/wiki/Language_Integrated_Query http://en.wikipedia.org/wiki/Language_Integrated_Query [2] http://www.impredicative.com/ur/ http://www.impredicative.com/ur/

icebraining 14y ago
"Strongly typed" != "Statically typed"
gambler 14y ago
The part of LINQ you refer to works by running a code generator against database schema before writing any code. In other words, it is not a language feature (you can generate code in any language), it is highly complex and it is a maintenance liability. Generally, any kind of code generation is a crutch. Ability to dynamically modify objects removes the need for it. The way to go in .NET is the opposite direction: Entity Framework with Code First approach.

Dn_Ab 14y ago

F# Type providers are a powerful solution to problems of the same class as your first example. http://research.microsoft.com/pubs/173076/information-rich-themes-v4.pdf http://research.microsoft.com/pubs/173076/information-rich-t... And smart use of data structures, algebraic types and composition for the latter. The benefit of this is you build a sort of theory for your game, sometimes it predicts and suggests things that would not have been obvious to you otherwise.