World: r3wp

yep, it is still there, I use 2.7.7.
I use this function to test:
f: func ['w] [type? get in construct compose [t: (:w)] 't]
>> f yes
== word!
>> f off
== logic!

forum topic is "Careful when Construct an object" on http://rebolforum.com, 
above link goes another topic. (a bug on forum, topic numbers changing)

I posted the bug report

Thanks Gregg!!! It works just the way I need it to work :)

The yes and no keywords of R3's CONSTRUCT were added at my request. 
We'll have to see whether the enhanced function can be backported 
to R2 safely. There are other changes as well, mostly safety changes, 
and a CONSTRUCT/only option that turns all of the tricks off.

Bug#651 details the changes - yes and no keywords, and unset-to-none 
translation - and bug#687 explains CONSTRUCT/only.

We'll have to see if there is any R2 code that will be broken by 
the change; if so, it won't happen. As a rule, backwards-incompatible 
changes are only made to R2 when they can be proven to not harm legacy 
code. There have been a few exceptions, and at least one mistake 
that predated (and inspired) the rule, but the exceptions have all 
been added functionality that doesn't change old functionality that 
is relied on in code. If nothing relies on yes and no not being keywords, 
or unset! values not being translated to none, then we're cool. As 
a counter-example, CONSTRUCT/only could be backported without question 
because it's a new option.

One caveat to new options: Once APPLY is backported (planned for 
2.7.8) then new options will need to be added to the end of the options 
list of functions, not in the middle. APPLY is positional when it 
comes to options.

This is already a concern for those using the R2/Forward backport 
of APPLY.

What is the easiest way to prevent sub-object sharing? I have very 
simple but nested XML structure, and I want to put records into objects. 
But I have one subobject. I want to have prototype object (class) 
and create instances filled with data, but I want to avoid subobject 
sharing ....

simply put: proto: context [name: none address: context [street: 
none]], and now I want to make instances, but those should not share 
address subobject ...

You're going to have to clone the subobjects, eg.
	instance1: make proto [
		address: make address []  ; Clone object to avoid sharing.
	]

Just define your own constructor, that is all

Ah, thank you very much ... I thought I could somehow avoid that, 
but that's ok ....

I put an init function in the class, and do any stuff there, then 
its much easier to manage.

a: make class [init]

you can also make a function which call init , if its there.


new: func[class spec /local obj][obj: make class spec if function? 
get in obj 'init [obj/init]]

if you keep the prototype as a block you don't need to do so
>> context proto

Nevertheless, the "use your own constructor" variant is the only 
"truly object-oriented" one

yes, my above one-line constructor func scales very well, since you 
can call new on sub-objects too, and it will take care of any things 
like creating empty new blocks and formatted strings on the fly, 
within the init func.

My suggestion would be more like:

my-class: make object! [
    new: func [...] [...]
]

my-class-instance: my-class/new ...

, but, you can use whatever suits your needs

yes, the power of rebol to define our own models  :-)

How is it again that one decodes a url? Sometimes I forget the simple 
things.

dehex ?

thanks

Is there something like "unmold"? I find myself needing to return 
a molded block back to a block all the time.

load

dope

remember to MOLD/ALL if you don't want to lose information.

I have r2 question.  I wont to convert integer value to binary but 
it comes out wrong.  Some tell me how?  The integer is above 255.

Tell us what you are doing

I trying to convert integer value to binary.

>> debase/base to-hex 512 16
== #{00000200}

thx you Izkata.

Dope doesn't work that well.

I think, that everybody processing REBOL strings using REBOL shall 
be aware of CureCode #1632. I should probably write an article about 
the subject somewhere to make life of at least some people easier.

Yes, it's a pity MOLD isn't the one which is the least "lossy" (vs 
MOLD/ALL) when it comes to serialising.
What can be done about it at this stage, though?

thing is load isn't the counterpart to mold.  'DO is.   and even 
then, even MOLD/ALL isn't a real serialization because shared objects, 
or series aren't shared anymore.


although they go a long way, and I have been using them extensively 
in many tools, MOLD & MOLD/ALL are just helpers, destined for advanced 
users who have very special requirements.

we need to build a REAL serialization dialect, one which rebuilds 
the data sharing, even in nested and co-occuring references to series 
and objects.

it's rebin

but we should not be forced to use a binary dataset for such things. 
 it can be expressed in source format.

just added an (very succinct) extended serialization example which 
would allow us to basically fix all the MOLD issues on LOAD directly. 
 it could be the basis for rebin, which could just be a compressed 
version of the source version to keep it (very) small.

just added ?

to curecode.

as usually, all datatypes would need to support this extended format, 
but since it would be managed directly within the native datatype 
handling it would be MUCH faster than if we tried to build some dialect 
for it in REBOL.  especially since the native has much more direct 
access to things like same?, and internal states like series index.

I have done some work on this to support reloading of shared & nested 
objects specifically and its easy enough to do (for me ;-), but it 
requires some deeper understanding of REBOL.


I agree with Ladislav, though, that serialization should be addressed 
more "completely" at some point, directly within the language. 


IMHO, The current implementation isn't a "bug" but rather an annoying 
limitation which has been known and put off as a "to do" for years, 
by everyone which is capable of solving it.

(cause its a very tedious and "not fun" thing to do)

also, there are nasty binding issues on serialization...  things 
like:

---------------------------------
a: "data"
f: does [print a]
o: context [
	a: "other data"
	f: does [print a]
]
set in o 'f :f
---------------------------------


how is this treated in MOLDing ?  these are hard cases to choose 
from a variety of paths, if we serialize only the o  object, then 
its f method is pretty much broken in current REBOLs.   

how would we handle this?  there are a lot of ways to play with the 
above, but no single method will ever cover all possibilites.  


so in the end, the serialization will never be "perfect", unless 
all data items are signed with a unique key which is retrievable 
at run-time and reusable at each interpretation (pretty much impossible).


IMHO all we can do is properly document  what can and cannot be serialized 
without risk of data corruption.  Currently, official & explicit 
documentation on this is vague at best.

Max, I had a specific issue in mind: (pre)processing of REBOL scripts. 
In that case, you we not need to worry about such issues as binding, 
shared objects, etc. I am quite comfotable with MOLD, since it does 
not look like a gotcha to me (not that I want to repeat that "MOLD 
is not a counterpart to LOAD" mantra), but SAVE clearly *is* a gotcha, 
since nobody sane would expect it to "distort" REBOL script when 
saving REBOL code obtained as a result of LOAD.

you we not
: "we do not"

in R3, there is save/all which stores in serialized format, which 
might solve that particular case (saving a whole script)