World: r3wp

extending the /only concept to support a block of words to import.

and only those from the available export list can be chosen...  so 
you have a double restriction.

what can be exported AND what you need imported.

yes, I even consider the "what you need imported" as more important 
- since the original writer cannot know that

and that is the core reason for the existence of SLIM.

its the basic PITL building block missing in REBOL.  (for me anyways)

well, that may depend on granularity. If the original module contains 
even the kitchen sink, then it is absolutely necessary ;-)

in R3, modules can enforce the invisibility, where as in R2 it can 
only be obfuscated.

hehehe

(but even that does not protect you against bloat, since you don't 
import the words, but the code still takes space)

slim also allows you to rename the words AS you are importing them, 
solving the name clashing cleanly and obviously.  This is very usefull 
when you are using frequently updated libs.  and is even more usefull 
when those libs aren't readily editable. (encrypted, compressed, 
etc)

yes... bloat is something that accords bragging rights.  when you 
build a graphic packages... a single window takes up 3-4 times more 
space than ALL of loaded code.  so in any serious app, growing to 
30-100MB of data... 20 kb of code is meaningless.

hum... there are two words missing in the above...

yes... BUT bloat is ONLY something ...

in an app I tried to build using R2 a single picture took 40MB.  
I need to edit 10000 of them and output them in a picture that take 
about 1GB of space.  saving 10kb... really I could care less.

right you are

now I'm not downsizing the philosophy of less is more, just that 
in many PITL apps, the data becomes the beast.

that's usually the case, especially with REBOL

liquid is a 40kb library when comments are removed.... I've seen 
similar packages for other platforms take up 1MB for download.

well , so much for R3fying liquid.  just stumbled upon a bug in make 
object that prevents liquid from working in R3.
I am not using the 'self attribute but its the same bug.

http://curecode.org/rebol3/ticket.rsp?id=802&cursor=35

I was finally able to work around the bug.  :-)
so convertion can continue for now


but the workaround will become impossible to apply at some point. 
its too low-level a problem to be properly addressed in every single 
opportunity... and its an ugly fix.

hmm, since it is about the deep copy, you can always replace it by 
doing it on your own

(but it may be "expensive", i.e. time-consuming)

Why is it deep copying an object within an object?  it shouldn't.

it should only deep copy series... no?

that is a change in R3: copy/deep now copies objects too. I am not 
sure, what was the reason for it, though, maybe we should ask in 
R3 chat?

WHAT THE FUCK!

If that doesn't change, unfortunately, I'll never use R3.

...or, you could raise that question in CureCode

...or in both places (Carthaginem esse delendam)

I definitely will, I didn't realize the /deep until you posted your 
first comment above.

I'll restate the above... 

if make object doesn't switch or allow copy not being deep , I'll 
never be able to use R3.  I already hated (but understood the reason 
behind) the series copy, but this is ridiculous.

objects aren't payload, they are contexts.

can you show a simple example of the behaviour you dislike? - just 
to make sure it cannot be circumvented easily

ladislav, I have object which contain 150 interconnected objects.

and multiple depths

aha, so, a kind of "general graph"

copying making a new instance of the master class cannot imply duplicating 
all of the internals which have to be unique... it makes no sense.

graphs of graphs.

just the series copying makes countless duplication of data already... 
at least if there was an option but there isn't... that is my problem.

right now I depend on inner objects being shared in every single 
serious application I write.

so, is this a simle example of the behaviour you dislike?

>> o: make object! []
== make object! [
]
>> p: make object! [x: o]
== make object! [
    x: make object! [
    ]
]
>> q: make p []
== make object! [
    x: make object! [
    ]
]
>> same? q/x p/x
== false

yep.

I don't even understand why you'd want to do so... its exactly like 
forcing a reduce everytime you copied a block.

I mean.. it being the default in make.... I can see where copy/deep 
on objects can be usefull, but not as the only way to create new 
instances of objects.

yes, I preferred the R2 behaviour too

I prefered the R1 even more.

I don't remember how R1 handled objects

it didn't copy anything.

they where identical clones, within only binding switched to new 
context.

all series data was shared... 
but its easy to copy on demand... its impossible to "uncopy"


the reason for the change was essentially that it made VID easier 
to use.

people didn't understand why changing one string would affect many 
faces.


to some degree, that side-effect is still there though...  fonts, 
para, edge, are now still shared accross all face of the same style, 
which makes a lot of sense.