Re: [Setup-tool-hackers] xst_file_close

[Tambet Ingo <tambet ximian com>]

On 14 Aug 2001 17:42:58 -0400, Arturo Espinosa Aldama wrote:
> 
> I think the xst_file_close and the error checking problems are different
> matters. As I told, Perl is not behaving in an uniform way: sometimes
> close (undef) seems to continue silently and sometimes it doesn't.

Interesting. I tried
for (my $i = 0; $i < 1000; $i++) {
    $fh = &xst_file_open_read_from_names ('non-existing-file');
    my @a = <$fh>;
    close $fh;
}

and perl didn't give me any warnings nor crashed.

> We could emit a warning (instead of failing, as Perl somentimes, just
> sometimes, does), to let the programmers know. xst_file_close and checking
> for errors are not exclusive, and I think we should use both. All of us

It's really hard to believe that perl's close function has such a bug.
If it finshes with error sometimes then I'm sure it has a good reason
for doing so. Our job would be to figure out the reason, not just hide
it an pretend nothing went wrong. 

There's also an alternative approach, IO::File standard module. That
returns file handle object so closing it would be 
$fh->close;
If $fh was undefed then it wouldn't have close method and it would fail
each time. Regulary.

> Regarding reporting, there is already a report infrastructure. I'm just
> going to code an example in the boot tool so you can learn how to use
> it.

Then it's miscommunication. I've asked in this same list 'how do I use
reporting' and noone answered. Then Chema told me it's deprecared, don't
use it at all. Then I wrote about 10 mails about my vision of reporting,
noone answered (Joakim mentioned it in a mail). Now You tell me I'm
stupid and need and example how to use it... What should I've done
differently? I can't count on how other backends do it, all of them do
things differently.

> I think there's an important thing to learn from this: this is nobody's
> project. Some people take care of some parts of the system and some others
> take care of other parts. When programming, there's no single correct way
> of doing things: every head is a world, and we shouldn't go around
> thinking we'll always get it our way. If somebody is not willing to let
> others take decisions on how some code/protocol/format is going to be,
> that person is never going to take off to big colaborative projects:
> sometimes you have to let go your ideas, and accept those from other
> people (read: sometimes).

Exactly. In this situation it is NOT right if everyone just keeps their
style and doesn't discuss with others. I try to discuss and noone
answers, everybody is busy with their own implementation.

> This is also why I take some steps forward without asking: because someone
> is always going to claim that it is broken/there's a better way/you
> shouldn't do that. Normally I comment with a few people just to filter
> those really bad decisions, and I take the care of sending an e-mail when
> I'm really not sure about what is best or the cost of making a mistake is
> too high.

I really don't agree that we should have xst_* function for everything.
Even for close. Believe me, perl's errors and warnings are there to help
finding bugs. It is broken if You just hide them.

Tambet


_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers