Skip Menu |
Report information
Id: 126758
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: tkook11 [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [RFC] bytes method in numerical types?
Download (untitled) / with headers
text/plain 386b
This would add a .bytes method (or similarly-named) that returns a Blob containing the Numeric's data. This would be the natural representation of the Numeric, and would take an optional parameter specifying endianness (should it be ignored for Num or give an error?) This would be useful in serializing data (to write to a file or a socket). A reverse method would be useful as well.
Download (untitled) / with headers
text/plain 1.3k
On Sat Nov 28 20:02:17 2015, tkook11@gmail.com wrote: Show quoted text
> This would add a .bytes method (or similarly-named) that returns a > Blob containing the Numeric's data. This would be the natural > representation of the Numeric, and would take an optional parameter > specifying endianness (should it be ignored for Num or give an error?) > > This would be useful in serializing data (to write to a file or a > socket). > > A reverse method would be useful as well.
This ties into the larger question on how to handle the parsing and output of binary data, something we most likely won't figure out in time for Christmas. So I don't think it'd be a good idea to add just this feature in isolation. However, please feel free to develop some kind of module that can serialize and deserialize binary data (you can even add methods to existing classes using 'augment', if you wish). You can also go around to places such as the Perl 6 IRC channel and discuss how to go about binary data handling. Simply put, I think at this point we'd do well to have an external module for prototyping binary data handling, and use that to figure out how we would like to do it in a future version of Perl 6 :) . (One final hint: some kind of serialization method would have to be defined for each numeric type, and not just on Numeric, since things like Complex or Rat or Int or Num would each need special handling.)
Download (untitled) / with headers
text/plain 1.6k
On Sun Nov 29 19:04:30 2015, lue wrote: Show quoted text
> On Sat Nov 28 20:02:17 2015, tkook11@gmail.com wrote:
> > This would add a .bytes method (or similarly-named) that returns a > > Blob containing the Numeric's data. This would be the natural > > representation of the Numeric, and would take an optional parameter > > specifying endianness (should it be ignored for Num or give an > > error?) > > > > This would be useful in serializing data (to write to a file or a > > socket). > > > > A reverse method would be useful as well.
> > This ties into the larger question on how to handle the parsing and > output of binary data, something we most likely won't figure out in > time for Christmas. So I don't think it'd be a good idea to add just > this feature in isolation. > > However, please feel free to develop some kind of module that can > serialize and deserialize binary data (you can even add methods to > existing classes using 'augment', if you wish). You can also go around > to places such as the Perl 6 IRC channel and discuss how to go about > binary data handling. > > Simply put, I think at this point we'd do well to have an external > module for prototyping binary data handling, and use that to figure > out how we would like to do it in a future version of Perl 6 :) . > > (One final hint: some kind of serialization method would have to be > defined for each numeric type, and not just on Numeric, since things > like Complex or Rat or Int or Num would each need special handling.)
The hypothetical .bytes method would contain only the raw data, without the type info. I was also thinking about a separate method, though, perhaps named .serialize, which contains type info as well as working on all types.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org