[FEATURE] Access module content programmatically

[WillDaSilva]

Is your feature request related to a problem?

There does not appear to be any way to access the content of a module object programmatically.

Describe the solution you'd like

Modules essentially have a mapping from string keys to object values. This could be exposed in the language through a builtin function that takes a module object, and returns a dictionary. It should be made clear that adding or removing from that dictionary does not edit the module, but editing mutable values in the dictionary will alter those values in the module.

This also solves the issue of not being able to list the members of a module programmatically, as once you have the dictionary of the module's content you can then call .keys() on it to get that list.

[Jason2605]

Interesting yeah. We currently have things like getAttribute / hasAttribute on classes, do you think it makes sense to follow suit and add these as a default to all modules created? Perhaps another method that gets all attributes. I know python, for example, has things like builtin functions such as dir() but I tend to prefer that they be methods and encapsulated within the class / module themselves. Maybe something like <module>.attributes() returns the dictionary.

For classes we would also need to consider access levels, would .attributes() return private methods also? Be good to hear your thoughts!

[WillDaSilva]

If you're willing to make breaking changes getAttribute/hasAttribute could be replaced by .attributes() on classes/modules, since having an attributes dictionary would straightforwardly provide the ability to get attributes, and check if they exist. Or all three could exist, since getAttribute/hasAttribute would be more efficient and easier to write. Which approach is used is a matter of taste.

A tangentially related question: Why does the dictionary .keys() method return a list instead of a set?

I don't think the dictionary returned by attributes should include private methods, just public ones. Access to private methods would be unchanged by the addition of this feature. The main use of this feature is to allow dynamic access to attribute names and values, which will generally only be needed outside of the class where only the public attributes should be accessed. This would be similar to how getAttribute/hasAttribute only work on public attributes.

[Jason2605]

Or all three could exist, since getAttribute/hasAttribute would be more efficient and easier to write. Which approach is used is a matter of taste.

Yep, this was the route I was proposing: hasAttribute() -> bool getAttribute() -> value attributes() -> dictionary

However we could probably extend these in multiple places. For example, calling get/has on classes results in an error as these only exist within the instance itself - this should probably change.

It also only checks properties defined on an instance, it does not check methods defined within the class (and therefore within the instance), this should probably change.

A tangentially related question: Why does the dictionary .keys() method return a list instead of a set?

It's a good question. My initial rationale was that for the main part the majority of users are going to iterate through the entire set returned from this method, this would end up being slightly more efficient with a list as you're iterating the first N elements. With a set you're iterating the full capacity ignoring null elements.

I don't think the dictionary returned by attributes should include private methods, just public ones.

Agreed 👍