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

WRITE should accept more datatypes for DATA. #2007

Closed
Siskin-Bot opened this issue Feb 15, 2020 · 0 comments
Closed

WRITE should accept more datatypes for DATA. #2007

Siskin-Bot opened this issue Feb 15, 2020 · 0 comments
Labels
Oldes.resolved Bugs/wishes with Oldes' fixes/features Type.wish

Comments

@Siskin-Bot
Copy link
Collaborator

Submitted by: rebolek

WRITE currently supports block!, string! and binary! for its DATA. While this is enough for file scheme, other schemes can benefit from more types. For example writing OBJECT! or MAP! directly into database.

write redis://localhost/my-object object [name: "Hurvinek" age: 9]

Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Unspecified Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#2007

Comments:

Rebolbot commented on Apr 1, 2013:

Submitted by: BrianH

WRITE in R3 is supposed to be a low-level function, more similar to R2's WRITE-IO than its WRITE; same goes for READ and READ-IO. That is why there is no READ-IO and WRITE-IO in R3: they're READ and WRITE in R3. That is why the only types WRITE accepts are string, binary, and a dialect block to break the rules for higher level schemes. In the case you give above, that is a job for a dialect block.

It's just something to consider. Another thing to consider is: Why are you using WRITE here? There are plenty of port operations, most of which take a wide variety of datatypes. Not saying that it is a bad idea, it just doesn't fit the model very well. It's possible to make schemes that fit different models in R3. You don't have to use the READ/WRITE model for everything.


Rebolbot commented on Apr 1, 2013:

Submitted by: rebolek

Why am I using WRITE here? It may be supposed to be low-level but actually it's the easiest way to use the port! as I don't have to open it before taking action (WRITE does it for me). Of course it can be done in dialect but it can be done in WRITE directly to make the code simpler.


Rebolbot commented on Apr 2, 2013:

Submitted by: BrianH

So why aren't you implementing the scheme's behavior with a dialect block? Dialect blocks can do everything you want here, and they make the WRITE model more consistent between schemes, especially for lower-level schemes like TCP that can't possibly support other datatypes.


Rebolbot commented on Apr 3, 2013:

Submitted by: rebolek

Of course I can implement dialect on top of the scheme, it's just that WRITE url! DATA fits the key/value storage model perfectly, so it feels natural to use. I can add custom REDIS-WRITE that will do what I want, I just don't understand why when it can't be solved in WRITE directly.


Oldes mentioned this issue on Jun 17, 2019:
Wish: add back READ/binary and WRITE/binary


Rebolbot added the Type.wish on Jan 12, 2016


Oldes commented on Jun 17, 2019:

I implemented this wish in this commit in my branch: Oldes/Rebol3@2433000
... and this is current function doc:

USAGE:
     WRITE destination data

DESCRIPTION:
     Writes to a file, URL, or port - auto-converts text strings.
     WRITE is an action! value.

ARGUMENTS:
     destination   [port! file! url! block!]
     data          [any-type!] Data to write (non-binary converts to UTF-8).

REFINEMENTS:
     /part         Partial write a given number of units
      length       [number!]
     /seek         Write at a specific position
      index        [number!]
     /append       Write data at end of file
     /allow        Specifies protection attributes
      access       [block!]
     /lines        Write each value in a block as a separate line

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Oldes.resolved Bugs/wishes with Oldes' fixes/features Type.wish
Projects
None yet
Development

No branches or pull requests

2 participants