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.
skybuck2000 wrote:
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----
Ned Latham wrote:
skybuck2000 wrote:
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?
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 ! ;)
skybuck2000 wrote:
Ned Latham wrote:
skybuck2000 wrote:
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?
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,
On Tuesday, December 31, 2019 at 2:15:23 PM UTC+1, Ned Latham wrote:
skybuck2000 wrote:
Ned Latham wrote:
skybuck2000 wrote:
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?
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,
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 ;) :)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 376 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 38:52:27 |
| Calls: | 8,039 |
| Calls today: | 3 |
| Files: | 13,037 |
| Messages: | 5,830,365 |