Split object into multiple files ?

Post by s***@hotmail.com
Can oberon do this, or has it repeated the mistake in Delphi ?
There is a very serious limitations in the object orientation in
Delphi programming language.
It's basically impossible to split an object into multiple files/units.

Can't you just Write() a number of bytes to file1, move forward that many
bytes, Write() that many bytes to file2, and so on?

----snip----

s***@hotmail.com

2019-12-31 05:48:09 UTC

Can't you just Write() a number of bytes to file1, move forward that many
bytes, Write() that many bytes to file2, and so on?
----snip----

:)

This is about splitting source into multiple files and compiling/using them inside a development environment to be able to develop large object orientated main computer program objects without having to store all the code in one big file which is kinda annoying with scrolling and other environment behaviour and less convenient when some of that code wants to be hidden by programmer from view to concentrate on the more interesting code, but still needs to be there part of the whole ! ;)

Just cleared that up for you in case I wasn't a joke ! LOL or somebody else don't get it ! LOL.

Bye,
skybuck ;) =D

Ned Latham

2019-12-31 13:15:18 UTC

Can't you just Write() a number of bytes to file1, move forward that many
bytes, Write() that many bytes to file2, and so on?

This is about splitting source into multiple files and
compiling/using them inside a development environment to be able
to develop large object orientated main computer program objects
without having to store all the code in one big file which is
kinda annoying with scrolling and other environment behaviour and
less convenient when some of that code wants to be hidden by
programmer from view to concentrate on the more interesting code,
but still needs to be there part of the whole ! ;)

For compiling it should be easy: decide on a splitfile size, divide
the composite file's size by that for the number of splitfiles then
split the file into that many pieces of that size, giving each a
filename of the pattern splifile_nnn, where nnn is the file's number
in the sequence in leading-zero notation so that the system accesses
them in the order you want.

Restoring it is just a matter of concatenating them.

Dunno about editing. Do you have a development environment or an
editor that offers buffered file access (like vim, for example)?

My development environment is g++, vim, X, blackbox, and xterm.
For programming I keep 6 xterms open on each desktop, each of
them having a different file open in vim. If you could do that
or something like it with your collection of splitfiles, you
might have a very low-maintence solution. The splitfile size
is needed only to generate the splitfileis efficiently, now
their size doesn't matter. If you edit splitfile_003.ext, for
example, that edit is what goes into the contcatenation, no
matter what the resultant size of splitfile.003.ext is. So
by editing the splitfiles, you're editing what has become your
original source code,

s***@hotmail.com

2020-01-07 23:04:08 UTC

Can't you just Write() a number of bytes to file1, move forward that many
bytes, Write() that many bytes to file2, and so on?

For compiling it should be easy: decide on a splitfile size, divide
the composite file's size by that for the number of splitfiles then
split the file into that many pieces of that size, giving each a
filename of the pattern splifile_nnn, where nnn is the file's number
in the sequence in leading-zero notation so that the system accesses
them in the order you want.
Restoring it is just a matter of concatenating them.
Dunno about editing. Do you have a development environment or an
editor that offers buffered file access (like vim, for example)?
My development environment is g++, vim, X, blackbox, and xterm.
For programming I keep 6 xterms open on each desktop, each of
them having a different file open in vim. If you could do that
or something like it with your collection of splitfiles, you
might have a very low-maintence solution. The splitfile size
is needed only to generate the splitfileis efficiently, now
their size doesn't matter. If you edit splitfile_003.ext, for
example, that edit is what goes into the contcatenation, no
matter what the resultant size of splitfile.003.ext is. So
by editing the splitfiles, you're editing what has become your
original source code,

The IDE, integrated development environment, must also be able to do:

1. Syntax highlighting
2. Debugging
3. Find declaration, so in-memory compiling.
4. Code insight/Code completion.

So there are many things that are affected by this.

For practical usage the IDE will have to support this splitting, by supporting the splitting in every possible way :)

Otherwise splitting the files/object becomes unpractical ;) :)

Bye,
Skybuck =D

Ned Latham

2020-01-07 23:48:55 UTC