e specific domain
$fh = new File::Text "blah" open($fh, "blah")
$txt = $fh->read$txt = <$fh>
etc.
There is nothing preventing a procedural interface. One only needs a
handle.
--
Chaim Frenkel
{
GB> my $me = ref($ME) ? $ME : $default_obj; # Pkg->dual_api is same as sub-call
GB> # process
GB> }
GB> So I am hoping that we get the object removed from @_ into an predefined
GB> lexical so the sub can more easily determine how it was called with
GB> little expense.
-
>>>>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Tue, Aug 15, 2000 at 10:14:36AM -0400, Chaim Frenkel wrote:
>> As much as I'm not for it, would
>>
>> having
>>
>> sub foo :method {} # In objects
of
production machines. I don't need documentation on the production
boxes.
Or what about a application that doesn't want to force the end-user to
install perl?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
ation on, have _NO_ direct human users. They
are purely application servers. I don't want a minimum stripped down
perl installation that will get my job done.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
nment I have a clean nice place
to work from either making a tarball or just using SysV packaging.
Why make life hard, an option can be a lot easier than having to
manually rm stuff. (I.e. rm everything except perldiag.pod.)
And what about when the installation changes? Or ....
Perl is a
7;ve done it wrong. It stays wrong until the machine is
replaced.
*sigh*,
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
and the rest. The embeded pod documentation is not
needed on a production only server. And if the .pm can be boiled
down to bytecode then there is no need for the .pm
Will you require that the .pm be installed on a production box just
so that embedded pod will be available?
--
Chaim Frenkel
process.
Please, make the Config.pm be internal. So it can not be seperated from
the executable.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183