Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAKE MODULE! accepts integer/decimal to make empty module with spec = none #1551

Open
rebolbot opened this issue Mar 29, 2010 · 4 comments
Open

Comments

@rebolbot
Copy link
Collaborator

Submitted by: meijeru

Like for many other target types, MAKE accepts a numerical second argument for MODULE! to make a module with an empty body. However, the resulting spec is NONE, which makes the module quasi unusable (import requires that spec/name is set).

>> m: make module! 10
>> body-of m
== []
>> spec-of m
== none

CC - Data [ Version: alpha 97 Type: Issue Platform: All Category: Datatype Reproduce: Always Fixed-in:none ]

@rebolbot
Copy link
Collaborator Author

Submitted by: BrianH

Actually, the resulting module is useless because it doesn't do anything. Unnamed modules are treated as mixins, so not having a name doesn't make a module inherently useless.

@rebolbot
Copy link
Collaborator Author

Submitted by: meijeru

I accept that a spec of NONE does not need to be useless. But -- as you rightly point out -- an empty module body is truly useless. It would not be so if one could append to a module after it has first been defined. But I seem to recall that you took a dim view of that (comments to #896).

In short: why allow an integer second argument to MAKE MODULE! ?

@rebolbot
Copy link
Collaborator Author

Submitted by: Carl

Let's hear both sides: why allow modules to extend? What use is it? And... Why not allow extend? What's the harm?

@rebolbot
Copy link
Collaborator Author

Submitted by: BrianH

Why not:

- It messes with the ability for module code to find out about their module through reflection on 'self. If the module can be extended from the outside, you won't be able to rely on self being the context in which your code was bound; it could be a little different. This can include code injection tricks (that Meijeru has demonstrated) if you are writing R2-style code; R3-style should be fine.

What use is it:

- It's a place to put your stuff, instead of in an object inside the module. Doesn't seem like a good practice though.

Why allow it:

- Because until the PROTECT bugs are fixed and enhancements implemented, we have no choice: You can do it anyways with the object returned by BIND?. See #1555 for details.
- I'm open to more suggestions here...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant